Does not work with UTC reliably around DST changes in local timezone about timezone-js HOT 3 CLOSED

Can you verify if the native JS Date object in the same timezone is afflicted with the same issue? A lot of these inconsistencies around the DST leap are not specific to the lib, they're just due to the fact that under the hood we're using JS Date.

from timezone-js.

It's somehow irrelevant how native object behaves because it doesn't support timezones and the bug is caused because I want to get Date object of different timezone than my local timezone.

But anyways, I switched my computer to UTC and ran the same tests, and everything is OK:

(new Date(1414281600*1000)).getHours()  // 0
(new Date(1414285200*1000)).getHours()  // 1
(new Date(1414288800*1000)).getHours()  // 2

If using native JS Date under the hood causes bad calculations then it simply means that this approach is flawed and should be abandoned.
I just had similar problems with python "croniter" library last week. It also runs calcuations on naive (local) datetime internally causing bad calculations around DST changes of computer timezone.

I understand that this is an open source project, a lot of work was put into it and I'm in no position to demand anything but I see a lot of similar tickets in the issue tracker. I think that in order to avoid a lot of frustration there should be at least clear information on main page that this library does not produce valid calculations of any timezone around DST changes of computer's local timezone.

from timezone-js.

The problems with native Date are relevant because the common issues file with this lib about DST leap involve how datetimes inside the leap-window are handled. Whenever someone files a bug related to the leap, I ask about that first. Native JS Date doesn't handle timezones, but it does handle the DST leap, and it does it in a way that is not necessarily what everyone Engineering is all about tradeoffs. If a particular approach has problems, it may still have enough other advantages to make it worth pursuing. I understand your frustration here, and it would be great if I had time to gut this library and start over. It's been around for almost 10 years now, and is pretty crufty. It seems to provide enough value for people that it's worth continuing to maintain.

If you'd like to take a stab at some sort of "caveat emptor" wording for the README, I'd be happy to update it. Note however "Does not produce valid calculations of any timezone around DST changes of computer's local timezone" is not in my experience a valid depiction of the behavior of the library, or a correct characterization of the various issues it has. I don't think that's quite fair.

from timezone-js.