Inconsistent offset near DST boundary

[neutraltone]

Information

Spacetime Version: v6.8.0
Example: https://codesandbox.io/s/inspiring-voice-qnons?file=/src/App.vue

Browsers Tested

• Firefox
• Safari
• Chrome

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 be 01-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 to America/Chicago the offset is incorrect again. Also, people working on the same application in the CST timezone are seeing the incorrect value.

Reproduction Steps

1. Set system timezone to Europe/London
2. Visit example link above and see that the dateCst is displayed correctly - 2020-10-31T23:00:00.000-05:00
3. Change system timezone to America/Chicago
4. Refresh code sandbox and see that dateCst timestamp is now incorrect - 2020-11-01T00:00:00.000-05:00

[spencermountain]

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

[spencermountain]

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.

[spencermountain]

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.

[spencermountain]

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.

[spencermountain]

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 - #182
cheers

[Nfinished]

Hi, still an issue I think? Unless I'm doing something silly. One hour off.

[HowieSquires]

@spencermountain Any update around this please?

[HowieSquires]

@spencermountain This might be a related bug:

spacetime('2025-03-30 01:00:00', 'utc').startOf('day').toNativeDate()

This seems to result in '2025-03-30 01:00:00'.

Note this is a DST boundary for the UK where my native is.

Any other time produces the correct result.