[mattdw]

Calendar events often want to be interpreted according to whatever the local timezone currently is. For instance "10am every second Sunday" shouldn't adjust to 9am during Daylight-Savings time. And my 7am alarm clock should definitely not change to 7pm because I flew from Aotearoa to England.

I'm sure it's been discussed here before, but for calendar events you don't necessarily want a timezone attached, you want a location - "this event happens at 9am according to whatever timezone is currently in effect in Auckland, NZ". That's a thing that UTC or timezone-aware Datetimes can't help with.

[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.

[paulryanrogers]

Even in your example those events do happen at a certain point in time. And if some attendees are virtual they may be several zones away. Ultimately people want to see their local TZ, whilst they want unambiguous data backing it.

Alarms are something of a special case, and with TZ aware types one could still adapt at the application later.

For a gift card system I once had relative expiration, enforced using the zone of the merchant location. Using a relative type actually felt like more work because from the merchant perspective, all that mattered was the point in time relative to their zone. It would've been simpler to do the offsetting in the app layer checks. And ultimately no one cared enough to keep maintaining it anyway, having an absolute point in time is usually good enough or even preferred.

[mattdw]

For events that have happened, absolutely. Events in the future are often slightly more ambiguous though!

I do agree that "with attached Timezone" or "as UTC" are absolutely the sensible defaults, I'm just suggesting that sometimes "plain" datetimes are semantically the correct choice.