[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?

[mceachen]

Each record encodes optional FROM and TO fields: https://en.wikipedia.org/wiki/Tz_database