-
Notifications
You must be signed in to change notification settings - Fork 184
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: change timezone and keep local time #180
Comments
Hey @havgry yeah, this is confusing, but is the expected behaviour. Maybe we should add this to the documentation more clearly, it is not very clear at the moment. |
Hmm, what I don't get is why there's a difference between initializing with a default timezone explicitly and initializing without and then using goto. The end result should be the same and it is - until DST gets involved. Notice how the last line is off by 1 hour compared to the rest. Second edit: I now realize what I posted last night was total garbage. The idea was to visualize it with to different dates (one on standard time and one on DST) like so:
What I don't understand is why Third edit: The problem seems to be alleviated by not using ISO 8601. But I don't feel much wiser :) |
ha, yeah. i get caught on this too. Maybe there's a clearer way to do it.
You can always see what timezone you're in with let a = spacetime('2020-02-10T14:00:00.000Z')
console.log(a.timezone())
let b=a.goto('europe/london')
console.log(b.timezone()) Let me know if that doesn't help. Goto should change the time. If youre in copenhagen, it makes sense that the initial date is in UTC+1 |
been thinking about this. Maybe we need a 2nd method that sets the timezone, but keeps the local time. |
Why not just use st.timezone('America/Denver') |
that's very clever. |
.goto()
combined with rolling in/out of DST yields unexpected behaviour
I just want to preface this by saying that I have no idea if this is a bug or it's the expected behaviour - but at the very least it's not clear to me from the documentation.
Anyway, I was scratching my head over future dates seemingly being wrong when rolling in/out of DST. For me, initializing in a specific timezone or initializing and then using goto, is the same thing. But spacetime doesn't agree - at least not when DST changes.
Can anyone explain this?
The text was updated successfully, but these errors were encountered: