Timeline label shows repeated months

[rafaelveloso]

More often than not, I get my timeline charts all messed up because I get repeated periods on the label. This caused all data to be shifted on the visual presentation, making it absolutely misleading.
Does this happen to anyone else and is there a way to fix it?

[mazameli]

Pretty sure this is a dupe of one of our many timezone related issues which should hopefully be fixed by a bunch of work @senior has done for 0.26. Does this issue look like that to you, @senior?

[mazameli]

Incidentally, @rafaelveloso, could you specify:

• your metabase version
• What is your database's timezone?
• Are you using an explicit time zone setting on each timestamp, or are the timestamps being stored without a timestamp? (E.g., Dec 1, 2019 00:00:00Z00 is an explicitly timestamped value, but Dec 1, 2019 has an implied time zone.)
• What time zone is the database server set to?
• What time zone is the server that is running Metabase set to?
• What is your Report Time Zone setting in the Metabase Admin Panel?
• What is your browser time zone setting?

[senior]

@mazameli that looks different to me. What we saw in the bugs I fixed were dates that were consistently off due to timezone shifting, i.e. no January and an extra June bar as opposed to the same month twice and missing a month. It would be good to get the info above though to see if we can recreate it.

[rafaelveloso]

@mazameli Thanks for the quick reply.
Let me know if you need anything else while trying to reproduce this.

your metabase version

0.25.2

What is your database's timezone?

UTC

Are you using an explicit time zone setting on each timestamp, or are the timestamps being stored without a timestamp? (E.g., Dec 1, 2019 00:00:00Z00 is an explicitly timestamped value, but Dec 1, 2019 has an implied time zone.)

I'm using timestamp with timezone on all my date fields, but all are using the database's default timezone.

What time zone is the database server set to?

UTC

What time zone is the server that is running Metabase set to?

UTC

What is your Report Time Zone setting in the Metabase Admin Panel?

Database Default

What is your browser time zone setting?

UTC

[ebalgava]

I'm having same issue with shifted date labels in charts:
https://bi.ekosystem.slovensko.digital/public/dashboard/86ce303c-05bf-4947-bb39-d2a958208492
@salsakran anounced 'this should be fixed in 0.26' but my issue still persists within v0.26.1:
#3642 (comment)

[tlrobinson]

@rafaelveloso @ebalgava @TeamDKS I believe we have a fix for this in #7247. Please give it a try and let me know if it does or doesn't fix this for you (and hopefully doesn't make things worse...)

[artem-levashov]

I had same problem with GA reports when usied yearMonth grouping. For me problem was in timezone. To fix it i made 2 steps

1. in Admin panel set report timezone to UTC
2. rewrote service which is running metabes. jar:
   from
   java -jar metabase.jar
   to
   java -Duser.timezone=US/Central -jar metabase.jar
   After restart all dates show correctly

[jlisyc]

related #9175

[dfx413]

Some additional info that may be useful: (from #10183 )

• When the X axis is set to "time series" the bar labels are wrong. However, the bar hover tooltips are correct.
• When I set the X axis to "ordinal" mode this issue disappears.

[EBoisseauSierra]

@mazameli As you hinted in your comment on #11067 this isn't solved yet (at least in v33.4).

Indeed, I have been able to replicate the issue:

Using this query on the sample dataset:

Note that its SQL translation replicate the issue as well:

SELECT "source"."CREATED_AT" AS "CREATED_AT", "source"."sum" AS "sum"
FROM (SELECT parsedatetime(formatdatetime("PUBLIC"."ORDERS"."CREATED_AT", 'yyyyMM'), 'yyyyMM') AS "CREATED_AT", sum("PUBLIC"."ORDERS"."QUANTITY") AS "sum" FROM "PUBLIC"."ORDERS"
GROUP BY parsedatetime(formatdatetime("PUBLIC"."ORDERS"."CREATED_AT", 'yyyyMM'), 'yyyyMM')
ORDER BY parsedatetime(formatdatetime("PUBLIC"."ORDERS"."CREATED_AT", 'yyyyMM'), 'yyyyMM') ASC) "source"
WHERE ("source"."CREATED_AT" >= timestamp '2019-01-01T00:00:00.000Z'
   AND "source"."CREATED_AT" < timestamp '2019-05-01T00:00:00.000Z')
LIMIT 1048576

---

My config is:

{
  "browser-info": {
    "language": "en-GB",
    "platform": "Linux x86_64",
    "userAgent": "Mozilla/5.0 (X11; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0",
    "vendor": ""
  },
  "system-info": {
    "java.runtime.name": "OpenJDK Runtime Environment",
    "java.runtime.version": "1.8.0_191-b12",
    "java.vendor": "Oracle Corporation",
    "java.vendor.url": "http://java.oracle.com/",
    "java.version": "1.8.0_191",
    "java.vm.name": "OpenJDK 64-Bit Server VM",
    "java.vm.version": "25.191-b12",
    "os.name": "Linux",
    "os.version": "4.13.9-300.fc27.x86_64",
    "user.language": "en",
    "user.timezone": "Etc/UTC"
  },
  "metabase-info": {
    "databases": [
      "postgres",
      "h2"
    ],
    "hosting-env": "unknown",
    "application-database": "h2",
    "run-mode": "prod",
    "version": {
      "tag": "v0.33.4",
      "date": "2019-10-07",
      "branch": "release-0.33.x",
      "hash": "9559406"
    },
    "settings": {
      "report-timezone": null
    }
  }
}

[flamber]

@EBoisseauSierra The PR was merged on master, which will be the upcoming 0.34.0
EDIT: There was some re-juggling done, so the fix landed in 0.33.5, which has just been released.