utcToZonedTime returns next day when time matches offset

[atomcorp]

Hello, first of thanks for your work, dates are such a pain, I don't even want to think about working on a date library 😫

Anyway, I've come across this issue with date-fns-tz, I've tried to make a reduced issue here: https://codepen.io/atomcorp/pen/gObqoyX

In short the following returns a Date object for the 24th not 23rd

utcToZonedTime(
  new Date('Thu Jan 23 2020 05:00:00 GMT+0000 (Greenwich Mean Time)'),
  'America/New_York' // -5 hours
);

It seems to happen when the inputted time matches the offset of the timezone. So if you move the time of the inputted date an hour back or forward, so it's different to the timezone offset, both utcToZonedTime and the native method return the same.

Like I said times are weird, so maybe this is expected behaviour!? 🤷‍♂️

[atomcorp]

Edit: see below

[atomcorp]

Ok, I've looked into this more. The issue is restricted to Chrome Canary (I'm on 81.0.4039.0). It's specifically related to do with Intl.DateTimeFormat which is used in tzTokenizeDate.

const dateTime = new Intl.DateTimeFormat('en-US', {
      hour12: false,
      timeZone: 'America/New_York',
      year: 'numeric',
      month: '2-digit',
      day: '2-digit',
      hour: '2-digit',
      minute: '2-digit',
      second: '2-digit'
    });

const date = dateTime.format(new Date(2020, 0, 25, 5, 0, 0));

// Chome 79/Firefox etc:  date === 01/25/2020, 00:00:00
// Chrome 81:  date === 01/25/2020, 24:00:00

Working example here

I haven't found any Chrome issues about this, I don't know whether this is a Chrome bug or a change in behavior that is upcoming. But 24:00:00 is an invalid time surely, so probably just a bug that hopeufly gets squished before it gets full released.

[atomcorp]

Ok final word! Sorry for using your issue queue for talking aloud to myself 😂

I filed a bug report with Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1045791

[marnusw]

Great @atomcorp. Thank you for submitting the Chrome bug report. At least you talk sense when speaking to yourself. 😛

[a1russell]

The Chrome issue was closed and marked as WON'T FIX. I guess this bug needs to be fixed in this library?

I have opened #41 since this issue was prematurely closed.

[atomcorp]

Yeah think so! Chrome team's suggested fix hour12: false, hourCycle: "h23" doesn't seem to work, but removing hour12: false does.

eg: https://codepen.io/atomcorp/pen/KKwjpZR?editors=0010

I haven't had a chance to see what impact that change will have on date-fns-tz

[joelmoss]

Ok, so this is also affecting zonedTimeToUtc() :(

[joelmoss]

Removing the hour12, and adding hourCycle: 'h23' to the getDateTimeFormat function in the tzTokenizeDate fixes it.

[joelmoss]

I just tried to create a PR with this, but the build and packaging process is all sorts of busted, with no documentation.

I would love to help, so maybe someone could help me out with the build? thx

[hyyan]

@marnusw ,@marnusw I proposed a fix for this one, in my environment it worked, but I could not run the tests for some reason

[joelmoss]

OK, so I tested the fix which does work on Chrome 80. However, it breaks on Chrome < 73.

So I tried changing the locale from en-US to en-GB, and that fixed it for all scenarios.

Great work @hyyan, but that will cause other issues on Chrome < 73, which is not that old of a browser.

[hyyan]

@joelmoss Ok , OK , this is trickier than I thought. I changed the code to test for predefined known case. this should solve the problem with all browsers now. Can you give it a try please and add your feedback, maybe @marnusw can merge then

[marnusw]

Thank you all. This was a tricky one to solve. Thank you @hyyan for making a PR. I will review and merge over the weekend.

[crazy4groovy]

Hi, experiencing this myself, but only on an Ubuntu Chrome browser, and no issue on a Mac Chrome.

As a test case:

['04', '05', '06'].forEach(h => {
  for (let i = 0; i < 60; i += 5) {
    const m = (i <= 9 ? '0' : '') + i;
    console.log(utcToZonedTime('2020-02-09T' + h + ':' + m + ':00.000Z', 'America/Toronto'));
  }
})

Sat Feb 08 2020 23:00:00 GMT-0500 (Eastern Standard Time)
Sat Feb 08 2020 23:05:00 GMT-0500 (Eastern Standard Time)
Sat Feb 08 2020 23:10:00 GMT-0500 (Eastern Standard Time)
Sat Feb 08 2020 23:15:00 GMT-0500 (Eastern Standard Time)
Sat Feb 08 2020 23:20:00 GMT-0500 (Eastern Standard Time)
Sat Feb 08 2020 23:25:00 GMT-0500 (Eastern Standard Time)
Sat Feb 08 2020 23:30:00 GMT-0500 (Eastern Standard Time)
Sat Feb 08 2020 23:35:00 GMT-0500 (Eastern Standard Time)
Sat Feb 08 2020 23:40:00 GMT-0500 (Eastern Standard Time)
Sat Feb 08 2020 23:45:00 GMT-0500 (Eastern Standard Time)
Sat Feb 08 2020 23:50:00 GMT-0500 (Eastern Standard Time)
Sat Feb 08 2020 23:55:00 GMT-0500 (Eastern Standard Time)
Mon Feb 10 2020 00:00:00 GMT-0500 (Eastern Standard Time)
Mon Feb 10 2020 00:05:00 GMT-0500 (Eastern Standard Time)
Mon Feb 10 2020 00:10:00 GMT-0500 (Eastern Standard Time)
Mon Feb 10 2020 00:15:00 GMT-0500 (Eastern Standard Time)
Mon Feb 10 2020 00:20:00 GMT-0500 (Eastern Standard Time)
Mon Feb 10 2020 00:25:00 GMT-0500 (Eastern Standard Time)
Mon Feb 10 2020 00:30:00 GMT-0500 (Eastern Standard Time)
Mon Feb 10 2020 00:35:00 GMT-0500 (Eastern Standard Time)
Mon Feb 10 2020 00:40:00 GMT-0500 (Eastern Standard Time)
Mon Feb 10 2020 00:45:00 GMT-0500 (Eastern Standard Time)
Mon Feb 10 2020 00:50:00 GMT-0500 (Eastern Standard Time)
Mon Feb 10 2020 00:55:00 GMT-0500 (Eastern Standard Time)
Sun Feb 09 2020 01:00:00 GMT-0500 (Eastern Standard Time)
Sun Feb 09 2020 01:05:00 GMT-0500 (Eastern Standard Time)
Sun Feb 09 2020 01:10:00 GMT-0500 (Eastern Standard Time)
Sun Feb 09 2020 01:15:00 GMT-0500 (Eastern Standard Time)
Sun Feb 09 2020 01:20:00 GMT-0500 (Eastern Standard Time)
Sun Feb 09 2020 01:25:00 GMT-0500 (Eastern Standard Time)
Sun Feb 09 2020 01:30:00 GMT-0500 (Eastern Standard Time)
Sun Feb 09 2020 01:35:00 GMT-0500 (Eastern Standard Time)
Sun Feb 09 2020 01:40:00 GMT-0500 (Eastern Standard Time)
Sun Feb 09 2020 01:45:00 GMT-0500 (Eastern Standard Time)
Sun Feb 09 2020 01:50:00 GMT-0500 (Eastern Standard Time)
Sun Feb 09 2020 01:55:00 GMT-0500 (Eastern Standard Time)

[crazy4groovy]

Ah! I do believe it's a Chrome 80 bug. I had Chrome 79 on my Mac, no issues. I just updated to 80, and now I see the bug.

Just confirming. Thanks.

[hyyan]

@marnusw did you have the chance to review?

[marnusw]

Thanks again all. Please check out 1.0.10 and let me know if there are still any issues.