[akio]

No. Local time should nearly always be used to represent the time of future physical events (along side a geographical location, such as an address).

Your method of using a named time zone like “Europe/London” is generally wrong for future physical events, and leads to bugs if and when the actual physical location of the event changes named time zones (which does happen).

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

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.

Physical future events are not a fixed instant on the universal timeline, they are a local time + a location.

[progval]

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

Not that in invalidates your overall point, but in that case the TZ database would create a new timezone (eg. named Europe/Dnipro) to reflect that from 1996 to 2030 it was UTC+2/UTC+3 (with EU DST rules); then switched to UTC+3 only.

This reflects that there is a place whose rules changed on 2030. Places don't move to an other existing timezone because that would prevent reasoning about past datetimes.

[akio]

Good point. As you mention, that doesn’t matter in this case, as even if a new named time zone is added, the stored named time zone would’ve been written before Europe/Dnipro was created (in case anyone’s wondering why this doesn’t invalidate the point).

[0cf8612b2e1e]

How do the time databases handle location renaming (eg in 2030, Dnipro becomes Putinville?

[danlitt]

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

I think in this case Europe/Kyiv would actually change its UTC offset to match Europe/Moscow, which I'm pretty sure the TZ database would handle just fine.

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

I think a sentence like this should jump out in big red letters. At face value it is not meaningful - how can our meeting time have not changed if the exact instant it occurs has changed?

If you chase this thought to its logical conclusion then it is not as obvious as you suggest. For instance, the number of hours between now and your proposed meeting has changed. Two meetings that happened to be simultaneous before now are no longer simultaneous because their relative UTC offsets changed. Is that a bug? What if your future physical event is the arrival of a train?

The choice in front of you is to pick a completely precise specification on which everyone agrees (the "instant of time") with an incomplete specification which you admit yourself may change in the future. My vote is to at least encode something unambiguous, and then to adjust it if my vague notion (local time) changes.

[1718627440]

> how can our meeting time have not changed if the exact instant it occurs has changed?

Because human time is not a numeric offset, but a name of relevant points.

> The choice in front of you is to pick a completely precise specification on which everyone agrees (the "instant of time") with an incomplete specification which you admit yourself may change in the future. My vote is to at least encode something unambiguous

The incomplete ambiguous specification is the one everyone agrees to, programmers just don't like them.

[akio]

> I think in this case Europe/Kyiv would actually change its UTC offset to match Europe/Moscow, which I'm pretty sure the TZ database would handle just fine.

Another user has already responded to the rest of your comment, so I’ll just respond to this.

In the Ukraine scenario Russia does not control Kyiv, so no, Europe/Kyiv would not change its offset.