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 https://github.com/spencermountain/spacetime/issues/235 is going to require a full re-write https://github.com/spencermountain/spacetime/issues/341#issuecomment-1845675753, 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 https://github.com/spencermountain/spacetime/issues/376#issuecomment-1875948871, or unsubscribe https://github.com/notifications/unsubscribe-auth/APCD3ZUPVHCXF4EOYX566E3YMW7ORAVCNFSM6AAAAAAVXCBVBWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZVHE2DQOBXGE . You are receiving this because you commented.Message ID: @.***>