Mismatched timeseries axes and labels in a Bar chart

[mmcf]

Using a custom question against a BigQuery view, I see a discrepancy between the timestamps reported in the axes and labels of a Bar chart. Incidentally, a Row chart displays correctly against the same data shows matched labels correctly.

• Browser: Chrome v68.0.3440.106 (64-bit)
• OS: OS X (v10.13.4)
• Databases: Google BigQuery
• Metabase version: 0.30.0 (using Docker image metabase/metabase:v0.30.0)
• Hosted: on Google Kubernetes engine
• Internal database: hosted via Google Cloud SQL PostgreSQL

Question definition

Bar Chart
Incorrectly showing events from 24th August against the 23rd axes label

Row Chart
Correctly showing events from 24th August against the 24th axes label (apologies, the axes label is very feint)

Raw Data

BigQuery - view data
Subset of data showing event_timestamp field stored as TIMESTAMP with timezone information

Having read through some of the other issues referencing timezones as a potential cause (e.g. issues 2340, 5246 and PR 7247), I can confirm that the Metabase server is running in UTC timezone, Metabase "Report Timezone" is UTC, and the underlying raw data in Bigquery is stored with UTC timezone. My browser timezone is currently set as BST (GMT+1) - manually setting this to an earlier timezone (e.g. Azores/GMT) fixes the display of the Bar chart (bars then appear under the correct axis label).

[kakobrekla]

It was suggested to me to add my observation of likely same bug.

I see an offset between the timestamps and labels on the x-axis. This affects bar, line, area and line+bar chart. Data found in table 'visualization' (as seen below) is correct.

• Browser: Chromium 67 (64-bit)
• OS: Ubuntu 17.10
• Databases: MariaDB 10.1
• Metabase version: v0.31.2 (running jar)
• Hosted: Debian stretch 9.6
• Internal database: MariaDB 10.1

Question

Result

Metabase jar is running with JAVA_TIMEZONE=UTC / -Duser.timezone=UTC, MariaDB is running in UTC zone, timestamp data is stored as unix timestamps.

Database timezone

[tlrobinson]

Probably related to #5916 and/or #5246

[antoine-lizee]

This is exactly the bug reported (and diagnosed) here: #5246 (comment)

I objectively don't understand why this has been deprioritized for so long. Isn't any user of Metabase relying on time axes? 🤔

Anyways, I'm very happy to see it back in the milestone :-)

[smic-datalabs-von]

Is there a workaround on this? This is quite an issue that might lead to misunderstanding of data.

[paulrosenzweig]

@smic-datalabs-von there's no workaround but a fix is coming. We've updated how Metabase communicates timezone info in its internal API. The next release shouldn't have this issue. Sorry for the delay in getting this fixed!

[antoine-lizee]

@smic-datalabs-von I shared a quick fix in my previous diagnosis of this problem there.
Basically, start another instance of chrome with a custom timezone that matches the one from your DB & Metabase. I've had this other instance of chrome running for a few months now...

[mazameli]

I'm pretty certain this is a duplicate of #4245, which, as I just noted there, is fixed in 0.33.6. Going to close this as such since I was able to repro this bug in 0.32.10, but it appears fixed for me in 0.33.6 and master. Please let me know if you're still experiencing this.