Feature: change timezone and keep local time

[havgry]

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.

const date = '2020-02-10T14:00:00.000Z'
const teatimeWinter = spacetime(date, 'europe/london').format('nice')
// Feb 10th, 2:00pm
const teatimeSpring = spacetime(date, 'europe/london').format('nice')
// May 10th, 2:00pm
const teatimeWinterGoto = spacetime(date).goto('europe/london').format('nice')
// Feb 10th, 2:00pm
const teatimeSpringGoto = spacetime(date).goto('europe/london').format('nice')
// May 10th, 3:00pm

Can anyone explain this?

[spencermountain]

Hey @havgry yeah, this is confusing, but is the expected behaviour. If you don’t supply a Timezone as a 2nd param, your local time zone Is used implicitly. Worse though, with an ISO date, the Z means use GMT, which Is what I think Is happening. When both are supplied, the explicit 2nd param wins.

Maybe we should add this to the documentation more clearly, it is not very clear at the moment.

[havgry]

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:

const teatimeWinter = spacetime('2020-02-10T14:00:00.000Z', 'europe/london').format('nice')
// Feb 10th, 2:00pm
const teatimeSpring = spacetime('2020-05-10T14:00:00.000Z', 'europe/london').format('nice')
// May 10th, 2:00pm
const teatimeWinterGoto = spacetime('2020-02-10T14:00:00.000Z').goto('europe/london').format('nice')
// Feb 10th, 2:00pm
const teatimeSpringGoto = spacetime('2020-05-10T14:00:00.000Z').goto('europe/london').format('nice')
// May 10th, 3:00pm

What I don't understand is why May 10th, 2:00pm suddenly becomes May 10th, 3:00pm when using goto.

Third edit: The problem seems to be alleviated by not using ISO 8601. But I don't feel much wiser :)

[spencermountain]

ha, yeah. i get caught on this too. Maybe there's a clearer way to do it.

.goto() calculates the time for that instant, in a new timezone. It was originally called .in() but i was getting caught on this exact thing. I thought goto was more clear.

You can always see what timezone you're in with .timezone():

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 cheers

[spencermountain]

been thinking about this. Maybe we need a 2nd method that sets the timezone, but keeps the local time. anyone have a good idea for a name? .setTz()? swapTz()?

[jecraig]

Why not just use st.timezone('America/Denver') That way it works the same as the other getter/setters like minute, hour, etc.

[spencermountain]

that's very clever.