[akio]

You are wrong, and fauigerzigerk is correct.

Future physical events, such as an appointment at a physical location, should be stored as unzoned time plus a location (such as an address), NOT with a named time zone.

This is because physical locations can change named time zones due to political reasons (this has happened many times already).

Storing an appointment time with “Europe/London” only works if your appointment is actually in London and not some other British city (and even that assumes that London never gets divided in the future).

If I say meet me in person at 10am March 5th, 2030 in Dnipro, Ukraine, that's specific to a location, not Europe/Kyiv.

Why? Because perhaps in 2030 Russia has taken over Dnipro and moved it from Europe/Kyiv to Europe/Moscow.

Our meeting time has obviously not changed, but its exact instant on the universal timeline has changed.

This is super important to get right and you are spreading incorrect information that, if followed, will lead to bugs.

[omnicognate]

If you're going to go to those lengths you will need a way to map the geographical location to a time convention (and you'll probably need something better than an address for the location as those can change too). I don't dispute there are use cases where that may be required, and it's not what I'm advising against.

What I'm explaining is that it's usually wrong to store a nominal (date)time that can't be resolved to an instant in time without assuming extra information that isn't captured.

If fauigerzigerk isn't arguing in favour of doing that, and I've misunderstood the prior discussion, then great. The point should be made anyway, because people doing that is by far the biggest cause of time-related software issues in my extensive experience.

[akio]

A future appointment at a physical location is usually an agreement between two or more humans. Humans generally don’t use UTC for future physical events, nor they use a time in a named time zone. What they use is a local time and location (often an address).

fauigerzigerk is saying that this, among with others, is the use case for what they are calling “local time,” what you are calling “nominal time,” what Postgres calls “timestamp without time zone,” and what the JS Temporal API calls “ PlainDateTime.”

In my experience engineers not understanding this key point, and believing that zoned time should be used for everything, is its own cause of issues and confusion.

[umanwizard]

You are technically correct but I’m not convinced it is “super important”. The stakes of not messing up appointment times in the very rare edge case of a territory changing time zones seems pretty low. I’m willing to be convinced that I’m wrong, though.

[akio]

It is not as rare as you might think.

The most recent time this happened was March of this year, with Chile's Aysén Region dropping DST and moving to the newly created America/Coyhaique.

https://data.iana.org/time-zones/tzdb/NEWS

I used to manage a large application for scheduling shifts at warehouses in many different locations, and storing future events as local timestamps and lazily converting them just before calculations into their location’s zoned time was the only way I could stay sane.