ISO offset vs IANA code ambiguities

[trouttdev]

We've run into an issue with DST while converting a datetime to a timezone that is already set to that timezone.

Example:

spacetime('2023-03-12T01:39:00-08:00').goto('America/Los_Angeles').time()

Produces 3:39am instead of the expected 1:39am.

This is the result from running it in the browser:

[spencermountain]

whoa, hi Michael, yep this is bad.
There is an explanation, but your example is very clear.

I'm re-doing this right now, in a branch. It's a bit of a head-scratcher - please allow me:

• iso-08:00 may be los angeles, or any Iana in -8. we assume Etc/GMT+8.
• spacetime('iso-08:00', 'America/Los_Angeles') will clarify this
• 'America/Los_Angeles' is sometimes in -7.
• likewise, spacetime('iso-08:00', 'Europe/Moscow') is ambiguous
• spacetime('iso-08:00').goto('Europe/Moscow') may be a different interpretation

I may look at how other libraries handle this. I may not have a full understanding of the problem. Maybe unclear inputs like 08:00, moscow should throw an error.

right now you can co-erce the timezone like this:

spacetime('2023-03-12T01:39:00-08:00', 'America/Los_Angeles').time()
//1:39am

but this should definetly get cleared-up. any help is welcomed.
cheers

[spencermountain]

you know what, I know what's happening.
this is another case of #235 in a sneaky way:

it creates a date at 1:39am in Etc/GMT+8 and then when you move it to LA, only then it becomes within an hour of a DST change, and so fails to guess which side of it it's on.

The example i gave works because it knows about the dst change at parse-time, so the correct interpretation is clearer.

super bad. not fun. i am working on a re-write to address this. will be the next release, but may be a week or two out. will keep this open, and add it as a test there.
cheers

[eshan-singh78]

is this bug fixed and if no , around which file might be causing this bug?

[spencermountain]

hey Eshan, sorry - there's no easy fix for this. #235 is going to require a full re-write, in order to fix properly. I plan on working on a fix for it over this year.
cheers

[eshan-singh78]

maybe rewriting with having each function having its own file will be easy to debug

…

On Thu, 4 Jan 2024 at 02:15, spencer kelly ***@***.***> wrote: hey Eshan, sorry - there's no easy fix for this. #235 <#235> is going to require a full re-write <#341 (comment)>, in order to fix properly. I plan on working on a fix for it over this year. cheers — Reply to this email directly, view it on GitHub <#376 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APCD3ZUPVHCXF4EOYX566E3YMW7ORAVCNFSM6AAAAAAVXCBVBWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZVHE2DQOBXGE> . You are receiving this because you commented.Message ID: ***@***.***>