spencermountain / spacetime

A lightweight javascript timezone library
http://spacetime.how/
Other
3.99k stars 183 forks source link

wrong offset within 1hr of DST start #182

Closed veddermatic closed 4 years ago

veddermatic commented 4 years ago

We are using spacetime to format dates, and when we changed to showing offsets, things got a little weird near DST boundaries. Looks like it tries to start it an hour earlier than it should?

That or I'm doing something horribly dumb, which is certainly a possibility as well.

// Sun Mar 10 2019 01:00:00 GMT-0500 (Eastern Standard Time)
const timestamp = 1552197600000;  // an hour before DST boundary

// make a date of that thing and see what it says
const _d = new Date(timestamp);
console.log( _d.toISOString()) // 2019-03-10T06:00:00.000Z

// make a spacetime of that thing in New York and see the same in UTC format
const _s = spacetime(timestamp, "America/New_York");
console.log( _s.format("iso-utc")) // 2019-03-10T06:00:00.000Z

// but these seem odd... should be T01:00:00.000-05:00 ??
console.log(_s.format("iso")) //  2019-03-10T03:00:00.000-04:00
console.log(_s.unixFmt("yyyy-MM-ddThh:mm:SSZ")) // 2019-03-10T03:00:00-0400

// make a date from the ISO format above
const _new = new Date(_s.format("iso"));
// and a new spacetime as well for fun
const _ns = spacetime(_s.format("iso"));

// see that we moved an hour by formatting
console.log( _new.toISOString()) // 2019-03-10T07:00:00.000Z
console.log(_ns.format("iso-utc")) // 2019-03-10T07:00:00.000Z

Note that near other boundary (1572757200000 with America/New_York as timezone) works fine.

spencermountain commented 4 years ago

hi Dave, thank you for the good issue. You're right, the timezone offset is often off by an hour, within an hour of a dst change. #106

This is, like you hinted at, a problem based on using the js Date object internally. It's a gross circle where we don't know the time without knowing the offset, and don't know the offset without knowing the time.

I will put this as a disclaimer on the Readme. You're right that it is only an issue during one DST change, which is why I've sometimes thought the issue was resolved.

I'd love some help on mitigating this problem, if anyone is interested, the code in question is right here

spencermountain commented 4 years ago

also, if I remember correctly, the worst-case is an hour-shy of the DST change - even if the timezone is -12h or something. Maybe we should confirm that 1hr of the official dst change is as bad as this can get. You can always get the offset info with _s.timezone().

That would be helpful - to confirm the worst-case scenario. If we knew this was always the case, in every timezone, we could just scoot the DST hour in the spring over by one. Maybe it's worse than that, though. ¯_(ツ)_/¯ cheers

veddermatic commented 4 years ago

Thanks for the confirmation. I'll make some time to see if I can help out on this in the next couple days.