[brewmarche]

Actually UTC + timezone is exactly the wrong thing for "wall clock times" (things like meetings or departures where the time at the location is relevant).

The conversion to UTC will lose the original local time so you cannot retrieve it once time zone data changes, unless you perform reconversions every time you detect such a change in tzdata. And countries changing time zones happens more often than we think (and also on short notice).

Thus it is important to distinguish between instants (e.g. for recording when exactly something happened after the fact) and wall clock time (e.g. for coordinating people and goods at a certain place, like meetings, concerts, departure times). For the former use UTC, for the latter use a localised time zone (e.g. Europe/Rome), not an offset time zone (e.g. not +0200).

For more information Jon Skeet has written about this multiple times.

[thomaslkjeldsen]

I believe this "wall clock time" approach is broken by design as it pushes the burden of figuring out timezone details to those who are not located in that particular timezone.

A fair and therefore safer approach is to decide that by protocol the legally binding time is defined in UTC.

Your system will translate UTC times to and from any given local time using the IANA time zone database which is regularly updated. End users must be aware about the UTC time, that it is legally binding, and that the local time conversions are provided as-is.

This way the time of a meeting or deadline is protected from local governments messing around with timezone changes.

Additionally, dates are rendered in ISO8601 standard format with a proper footnote to help users learn about international standards.

[brewmarche]

I think whether UTC or wall clock time is binding is a problem in the legal and planning (so the business) domain and has to be treated as an external input to the software engineering problem.

Although you are of course free to advocate for UTC. I remember Swatch trying to establish something similar and it never took off: https://en.wikipedia.org/wiki/Swatch_Internet_Time

[alanfranz]

> The conversion to UTC will lose the original local time so you cannot retrieve it once time zone data changes, unless you perform reconversions every time you detect such a change in tzdata

I don't agree/disagree with your point, and neither I do agree/disagree with GP on the topic, but why couldn't I retrieve the original time? If, for an event, I save UTC + event TimeZone, I can always get back to the original time (actually, it doesn't even matter whether the timestamp is UTC; it's enough for it to have an explicit offset, i.e. to be the representation for an instant). Why should I change the timezone on a saved record? What usually changes is the user's timezone, not the records'.

> Thus it is important to distinguish between instants and wall clock time

Yes.

> For more information Jon Skeet has written about this multiple times.

I have read many things on datetime; would you care to share a couple of relevant links?

[brewmarche]

Offset timezones (e.g. UTC+2) don't change, what changes are local timezones (e.g. Europe/Rome).

For example here Turkey decided to change daylight savings time: https://github.com/JodaOrg/joda-time/issues/403 (if you have a look at the tzdata database you will find more, this one I remember because Turkey went back and forth about this).

If your timezone database changes you cannot retrieve the original wall clock time, unless you have a temporal timezone database and remember the date of conversion to UTC.

And if you used offsets instead of local timezones to begin with, you cannot even infer which offsets to change unless you have location data saved as well.

Here is a blog post by Jon Skeet https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a... where he says:

> For me, the key difference between the options is that in option 3, we store and never change what the conference organizer entered. The organizer told us that the event would start at the given address in Amsterdam, at 9am on July 10th 2022. That’s what we stored, and that information never needs to change (unless the organizer wants to change it, of course). The UTC value is derived from that “golden” information, but can be re-derived if the context changes – such as when time zone rules change

[alanfranz]

I'm sorry for the late response; yes, you are right that for future events the "right way to do it" is saving the place + local time. I think we were speaking of slightly different things.

[brewmarche]

No problem. Yes this is for future events where we want to coordinate people at a certain place.

For recording when something happened use UTC or UTC plus fixed offset.

Do you have a third context of using time?