On: Footguns with Postgres "at time zone 'UTC'"

[masklinn]

A ZonedDateTime is not an instant and a timezone, for the same reason that you can’t unambiguously round trip between arbitrary timezones and UTC:

- zoned datetimes carry ambiguities as to their actual location on the timeline (because they can repeat, or not exist at all)

- future zoned datetime carry outright uncertainty as to their actual location on the timeline (as the zone’s offset can be updated at any point and any number of times until the event has elapsed)

[rawling → masklinn]

Has anyone proposed versioning timezones? Or is this such an edge case it would be overkill? (Either specify your future instant in UTC if you mean to stick to that, or specify it in a timezone and accept that it could change before it happens, or if you need something else get it in a contract and don't trust the computer!)

[pseidemann → rawling]

There is actually a simple heuristic you can use: if a point in time should be sticky to a calendar (e.g. calendar app or appointments which need to be synchronized between multiple humans or parties for a given context/location/region), store a datetime _without_ a timezone and make the timezone configurable for the user/infer it from the user. If you want a point in time which will not "physically" change, store a datetime _with_ a timezone, always, preferably UTC (e.g. logging, timers, measuring the occurrence of events).

[masklinn → rawling]

It’s really not clear what you’re asking.

The point of using zoned events is to match the life and expectation of people living in the real world e.g. if there is a meeting in Perth at 10AM, and the Perth timezone gets shifted, the meeting is still occurring at 10AM perth time. If it’s broadcast then every other time is what changes (or not).

If people want to fix their meeting internationally they can already do that by setting their meeting time in UTC.

[paulddraper → masklinn]

A java.time.ZonedDateTime is not simply zoneid+date+time.

It has the zone offset and so is completely unambiguous and invariable.

  private final LocalDateTime dateTime;
  private final ZoneOffset offset;
  private final ZoneId zone;

Converting Instant+ZoneId into a ZonedDateTime can vary according to the zone rules. Vice versa does not.

[ulrikrasmussen → masklinn]

Ah, yes, you are right! Forgot about those two details