Open neutraltone opened 3 years ago
hey @neutraltone thanks for the issue.
got a question - is there a reason why you're parsing the iso as UTC, and then stepping to chicago?
return spacetime(this.dateUtc, "Etc/UTC").goto("America/Chicago").format("iso");
instead of spacetime(date, 'america/chicago')
?
that may be the reason for the tricky-business. Another possibility may be that the iso has the offset hard-coded, so your actual timezone is being over-written. You can check the tz with d.timezone()
.
lemme know if that helps. You're right that 6.8.0
has changed behaviour when very-close to a dst-change.
There was a known issue before that's been fixed, so my gut is that the current behaviour is desired, but guts are wrong!
cheers
hah, sorry. I spoke too soon. Just found an issue - it's probably the same as yours. Will check it out and get back to you.
here's a reproduction, if it's helpful.
//set a time 10mins before a dst-change
let s = spacetime('Oct 25th 2020 2:50am', 'europe/brussels')
console.log(s.format(), s.time()) // time is right
//dst should be true.
console.log(s.timezone().current.isDST + ' should be true')
this passes on my computer, between 7pm and 9pm only - amazingly, this is when I wrote the tests and published 6.8.0
.
I'm EST, but the tests run in UTC-0, i think.
here's the same example for Chicago, which only works from midnight->2am (on my computer)
let s = spacetime('Nov 1st 2020 1:50am', 'america/chicago')
console.log(s.format(), s.time())
console.log(s.timezone().current.isDST + ' should be true')
ughh.
so, the good news is that these two timezones are 7hrs apart, and the window that they work is 7 hours apart, so maybe it's just a matter of accounting for the utc window that they work for in some way.
slept on this a few nights,
since we repeat an hour in fall-dst, there are 2 1:00am
hours, one with dst-on, and one with dst-off.
it's always going to be ambiguous which hour we are going to land on, when we sat 1:30am
.
but unfortunately, spacetime seems to be picking different ones, based on which time it is locally - as though it comes at it from different directions.
haven't got a fix yet.
my plan is to pre-compute dst changes as epochs. This will let us guess dst-dates in the future, as well.
for reference, here is the original issue, from 2020 - https://github.com/spencermountain/spacetime/issues/182 cheers
Hi, still an issue I think? Unless I'm doing something silly. One hour off.
Information
Spacetime Version: v6.8.0 Example: https://codesandbox.io/s/inspiring-voice-qnons?file=/src/App.vue
Browsers Tested
Hi, I'm experiencing a problem with timestamps that are near the DST boundary and converted to CST when the users system is set to CST as well.
I have a timestamp which is being returned from my API in UTC, I'm then using spacetime to then convert this to CST. Prior to the recent release which included pr #233, (If I recall correctly) the offset of the timestamp after converting to CST was wrong regardless of my system timezone (
01-11-2020T04:00
would always be01-11-2020T00:00
).After the most recent release the time is fine when I have my system set to
Europe/London
but when I change the timezone on my Mac toAmerica/Chicago
the offset is incorrect again. Also, people working on the same application in the CST timezone are seeing the incorrect value.Reproduction Steps
Europe/London
dateCst
is displayed correctly -2020-10-31T23:00:00.000-05:00
America/Chicago
dateCst
timestamp is now incorrect -2020-11-01T00:00:00.000-05:00