Luxon: Wrong date calculation in certain chrome version after using setZone()

[notlikethis1]

    var isoString = "2019-10-10T10:00:00.000Z";
    var start = DateTime.fromISO(isoString);

    for (var i = 0; i < 24; i++) {
        var nozone = start.plus( Duration.fromObject({ hours: i }));
        var withZone = nozone.setZone("Asia/Beirut");
        console.log("iso nozone", nozone.toISODate(), nozone.toISOTime());
        console.log("iso withzone", withZone.toISODate(), withZone.toISOTime());
        console.log("nozone", nozone.day);
        console.log("withZone", withZone.day);
    }

you will notice the withZone day go from 10 -> 12 -> 11

around the record for the wrong date, the iso string goes from
"iso withzone 2019-10-10 23:00:00.000+03:00"
to
"iso withzone 2019-10-12 00:00:00.000+27:00"
to
"iso withzone 2019-10-11 01:00:00.000+03:00"

in the browser versions that go wrong.

Doesn't happen in
Version 78.0.3904.97 (Official Build) (64-bit)

Does happen in:
Version 80.0.3966.0 (Official Build) canary (64-bit)
Version 80.0.3964.0 (Official Build) dev (64-bit)
Version 80.0.3964.0 (Official Build) dev (32-bit)

[icambron]

I got another report of that in #615. And seems to be a bug in newer versions of Chrome itself. It's possible that Luxon can work around it, but I'd like to start by submitting the bug to Google. I believe you should be able to reproduce it with:

new Intl.DateTimeFormat("en", { hour: "numeric", minute: "numeric", day: "numeric", "month" : "numeric",  "year": "numeric", "timeZoneName": "short", timeZone: "Asia/Beirut"}).format(new Date("2019-10-11 00:00:00.000+03:00"))

Can you give that a try and see if it returns something other than "10/11/2019, 12:00 AM GMT+3"? I will eventually install the canary build and try this out, but I haven't yet.

[notlikethis1]

Hi and thanx @icambron
unfortunately all browsers i tried return "10/11/2019, 12:00 AM GMT+3"

[dready]

Hi, just ran into this....

you need to use Chrome Canary https://www.google.com/chrome/canary/ to reproduce this problem.

bests, thomas

[notlikethis1]

you need to use Chrome Canary https://www.google.com/chrome/canary/ to reproduce this problem.

icambron's code for reproducing this:

new Intl.DateTimeFormat("en", { hour: "numeric", minute: "numeric", day: "numeric", "month" : "numeric", "year": "numeric", "timeZoneName": "short", timeZone: "Asia/Beirut"}).format(new Date("2019-10-11 00:00:00.000+03:00"))

doesn't show anything out of the ordinary for the canary browser that does show the wrong date with my luxon code.

I agree, if we have a suitable way to demonstrate the issue in chrome (with native js) i would be more than happy to file a ticket with them.

[icambron]

Hmm, I'd have really expected that to print the wrong thing. Seems like I'll have grab the canary build and trace through it. Might get to that this weekend

[icambron]

Ah, I was missing the hour12: true argument from the code I was hoping would reproduce it. When I add it in, the bug shows up bright and clear:

var d = new Date("2019-10-11 00:00:00.000+03:00")
new Intl.DateTimeFormat("en", { hour: "numeric", minute: "numeric", day: "numeric", "month" : "numeric", "year": "numeric", "timeZoneName": "short", timeZone: "Asia/Beirut", hour12: false }).format(d);
"10/11/2019, 24:00 GMT+3"

So Chrome isn't doing things right at all.

Luxon's doesn't parse that GMT+3 (it can't; that thing often says stuff like "EST"); instead it uses the hours there and decides that Beirut apparently has an offset of +27 hours.

[icambron]

Filed with Chrome here: https://bugs.chromium.org/p/chromium/issues/detail?id=1025564&can=2&q=%2224%3A00%22%20datetimeformat

[icambron]

I was able to workaround this in Luxon. Fix is 63122c7f74241db4bbccd1dcd0c7f70d8bec7579, released in 1.12.2. I'll remove that hack when the Chrome bug is fixed.

[icambron]

The good folks at Google have informed me this is in fact according to spec. Which is means that basically the "workaround" is here to stay. Which is fine; it works.

[notlikethis1]

@icambron thanks for the head-ups. We'll see what happens when this behavior is implemented in the non-dev chrome build. Maybe they'll have a change of heart when more people start complaining. Anyways, thanks for following up. We will keep a chrome dev version test in the test plan :-)

[icambron]

@notlikethis1 It's now in the main Chrome channel. I wrote this update because I've had an influx of new reports by devs who aren't on the latest version of Luxon.

I'm also going to try out a slightly cleaner fix once I have a chance to test that it works on other browsers and supported Node versions

[notlikethis1]

@icambron jup, stuff broke here also :'( Well the patch with your latest build is tested and ready to deploy monday.