[9dev]

If you want to make this a nitpicking discussion about phrasing a provocative statement, sure. If we’re talking about what matters, I stand by the notion that any point in time should be recorded in UTC, full stop. Storing a different time zone only makes sense if something happens at the same time in multiple time zones, but use cases are few. In the vast majority of scenarios,calculating the offset of the client and showing the adjusted date is the correct solution.

[chrismorgan]

The context was specifically the handling of times that don’t include an offset (or perhaps time zone, it was unclear). The correct answer there is not UTC (which is flatly incorrect, depending on a locally-enforced convention that incidentally deviates from the most common meaning of such time stamps), but rather “don’t enter that situation in the first place, because any other answer is wrong”.

—⁂—

For the rest of your statement: for times not tied to a particular location or time offset, you should always use UTC in the form of the offset Z, in ISO 8601/RFC 3339 terms, since specifying any other offset indicates that it means something. (Note that RFC 3339 tried to have -00:00 be the neutral offset and Z and +00:00 meaningful, but that is acknowledged to have failed, and so https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e... is updating it to match actual usage.) But for things that involve humans and are anchored to a particular time zone, using UTC and not storing a time zone is wrong: you should store the relevant time zone and (fallback) offset so that if the time zone definition changes (as they do, sometimes with less than a few days’ notice), future times can be corrected, which they can’t be if you anchored them to UTC. So: things like system logs, use UTC; online conferences, use UTC; location-bound conferences, use that location’s time zone; general user calendars, use the user’s time zone; calendars for companies that straddle time zones (or people that work across time zones): deliberately choose a time zone or offset to anchor things to (sometimes at the level of individual events), especially for the sake of recurring event periods if you use a time zone with DST.

[HelloNurse]

It isn't nitpicking, it's really a different type: 15 oct 2022 at 19:01 CET with DST, i.e. an instant, vs. 15 oct 2022 at 19:01 in an unspecified time zone, i.e. a set of about 25 instants (one per possible timezone).

While a datetime without a timezone isn't terribly useful, distinguishing it from a datetime and timezone designation pair is the only correct type system.

[addaon]

Why UTC instead of TAI?

[chrismorgan]

Because that’s not what TAI is designed for. UTC is for civil time keeping, and that’s what everything except highly-specialised stuff is tied to. The ISO 8601/RFC 3339 serialisation is UTC-based, so you’ll have to go heavily non-standard to use TAI, and you’ll find a complete lack of support in general date time libraries, so 37 second errors are sure to crop up all over the place if others ever touch things.