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 3 days ago | parent | next [-]

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 3 days ago \| parent [-]
		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 3 days ago | parent | prev [-]

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 3 days ago | parent [-]

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.

▲

umanwizard 3 days ago | parent | next [-]

I didn’t mean it’s globally rare, i.e. rare that it happens anywhere. I meant that it’s a rare thing for any given person to experience.

Even for people who live in Aysén, it will probably only happen once in their lives, and the only impact will be a few appointments getting messed up. Is having to fix a few calendar entries once in your life really “super important” to avoid?

	▲	akio 3 days ago \| parent [-]
		The consequences could look something like 50 shift workers showing up an hour late one day, or a user missing a critical meeting. Dealing with and debugging time zones is already such a confusing mess that I find that anything that makes your application more correct with regards to time zones is worth it. The important thing though is knowing, and then you can make an informed decision on how may shortcuts you want to take with time zones. If you’re writing software that’s only designed to be used in a small region or by just a few people, then sure, it’s probably not super important. If you’re writing software that’s used all over the map in places and time zones you can’t predict, well, it helps me sleep better at night.

▲

omnicognate 3 days ago | parent | prev [-]

Why didn't you store them as instants (offset from epoch) or UTC? Using local times, wouldn't your software produce different points in time for the same event when run with a different locale?

▲

akio 3 days ago | parent [-]

The events in question happen at a physical location at a local time, and so are stored as a local time plus longitude and latitude.

If they were stored as instants, and then if a location moved time zones or stopped using DST in the summer, the event’s stored time relative to the expected local time would incorrectly shift.

▲

omnicognate 3 days ago | parent [-]

That's logically fine, although it strikes me as likely overkill since your system has to be able to look up a convention by lat/long in order to get an instant in time, which is not trivial to do and for most use cases would be a more frequent source of errors than changing timezone definitions. I don't know the details of your use case though, and this could well be the appropriate representation. The main thing is that enough information is present to identify an instant in time. Your scheme isn't the nominal-datetime-only representation that I pointed out is frequently used but rarely correct.

	▲	akio 3 days ago \| parent [-]
		We agree that you generally want some information that lets you resolve your event to an IANA time zone for calculations :)