Closed wkeese closed 4 years ago
Howdy, sir! I remember you from when I contributed all the date-related stuff to Dojo. Hope you're doing well. Honestly, I haven't touched this code in a very, very long time, and this repo is mostly just here for posterity. Moment did a great job of attacking this problem space, and I moved on to other things. Is there some specific reason you're needing to use this?
Hi Matthew! Wow, that's going back a ways -- according to https://bugs.dojotoolkit.org/ticket/1385, 12 years ago. I must really like you :-) because not only am I using this timezone-js package, but I'm also using your dojo date arithmetic code... connecting them together via an awful hack because the date arithmetic code doesn't have an API to specify which Date class it uses.
It does seem like Moment has done a great job, specifically having the timezone support and arithmetic support in one library. Not sure why I didn't use Moment to begin with; perhaps eventually I should switch.
Anyway, I don't really need this fixed, nor do I even know how to fix it. I just spent some time tracking it down so I thought I should make a record of it.
This library is no longer maintained.
Dates created with a year <= 100 (ex:
new TimezoneJS.Date(99, 1, 1))
don't work correctly. Most of the timezone-js Date object, includingthis.year
and_dateProxy
, gets initialized correctly, but not_timeProxy
, due to this line in timezone-js/date.js:That doesn’t work because since this.year === 99 (2 digits long), Date.UTC() interprets it as 1999.
Not sure how to fix it or if it can be fixed; according to https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/UTC, Date.UTC() is operating according to spec: