-
Notifications
You must be signed in to change notification settings - Fork 184
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wrong offset within 1hr of DST start #182
Comments
hi Dave, thank you for the good issue. 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 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. ¯_(ツ)_/¯ |
Thanks for the confirmation. I'll make some time to see if I can help out on this in the next couple days. |
Solved to Chicken and Egg Problem described in summerTime.js: "we can't get the date, without knowing the timezone, and vice-versa". In order to eliminate the time zone offset effect the given UTC time is compared to the DST change boundaries converted to UTC.
Fix issue #182: wrong offset within 1hr of DST start
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.The text was updated successfully, but these errors were encountered: