3 ms·
> That's a thing that UTC or timezone-aware Datetimes can't help with. Modern datetime systems (including Temporal) use identifiers rather than offsets, which
by bakkoting 2y ago
> That's a thing that UTC or timezone-aware Datetimes can't help with.
Modern datetime systems (including Temporal) use identifiers rather than offsets, which are almost as good as a location as long as governments don't redraw the boundaries. And Auckland is in fact the canonical city for the main New Zealand timezone, so specifying your timezone as "Pacific/Auckland" will get you pretty much the thing you want. In Temporal, this would be e.g.
Temporal.PlainDateTime.from({ year: 2025, month: 1, day: 1, hour: 9 })
.toZonedDateTime('Pacific/Auckland')
- mattdw 2y agoFor sure, but for future events to be correct I still have to store that as (plain datetime, pacific/auckland), not translated to utc at the point of creation/saving. If I store only a UTC datetime I have unrecoverable lost important information.
- burntsushi 2y agoThat's exactly why Temporal uses RFC 9557 for its `ZonedDateTime` serialization format: >> zdt = Temporal.Now.zonedDateTimeISO() >> zdt.toJSON() "2025-01-24T19:57:01.089557834-05:00[America/New_York]" >> zdt.toString() "2025-01-24T19:57:01.089557834-05:00[America/New_York]" Temporal will even check that the offset is still correct for the time zone when you deserialize.
- Anon1096 2y agoThe alarm that I have set for 8AM every day shouldn't change to 3AM just because I moved time zones.