[bakkoting]

> 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]

For 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]

That'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]

The alarm that I have set for 8AM every day shouldn't change to 3AM just because I moved time zones.