Skip to content
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

Closed
veddermatic opened this issue Jan 13, 2020 · 3 comments
Closed

wrong offset within 1hr of DST start #182

veddermatic opened this issue Jan 13, 2020 · 3 comments
Labels

Comments

@veddermatic
Copy link

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
Copy link
Owner

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
Copy link
Owner

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

@spencermountain spencermountain pinned this issue Jan 14, 2020
@spencermountain spencermountain changed the title format produces incorrect values near DST start wrong offset within 1hr of DST start Jan 14, 2020
@veddermatic
Copy link
Author

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

bsvetlik added a commit to bsvetlik/spacetime that referenced this issue Oct 28, 2020
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.
spencermountain added a commit that referenced this issue Oct 28, 2020
Fix issue #182: wrong offset within 1hr of DST start
@spencermountain spencermountain mentioned this issue Oct 28, 2020
Merged
@spencermountain spencermountain unpinned this issue Oct 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants