date-fns-tz: utcToZonedTime returns next day when time matches offset

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!? 🤷‍♂️

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 1
Comments: 17 (6 by maintainers)

Commits related to this issue

fix : utcToZonedTime returns next day when time matches offset fix #38 — committed to hyyan/date-fns-tz by hyyan 4 years ago

Most upvoted comments

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

marnusw on Feb 10, 2020

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.

marnusw on Feb 7, 2020

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 on Jan 26, 2020