Open trouttdev opened 1 year ago
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 thisspacetime('iso-08:00', 'Europe/Moscow')
is ambiguousspacetime('iso-08:00').goto('Europe/Moscow')
may be a different interpretationI 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
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
is this bug fixed and if no , around which file might be causing this bug?
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
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: @.***>
We've run into an issue with DST while converting a datetime to a timezone that is already set to that timezone.
Example:
Produces
3:39am
instead of the expected1:39am
.This is the result from running it in the browser: