Closed veddermatic closed 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
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
Thanks for the confirmation. I'll make some time to see if I can help out on this in the next couple days.
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.
Note that near other boundary (
1572757200000
with America/New_York as timezone) works fine.