On Thu, 7 Oct 2021 at 16:23, Clive D.W. Feather <clive@davros.org> wrote:
Proposal: Ensure all of these are in `backward` Consider: Is there any way to move these IDs to the obsolete file? Maybe after 5 years? Or do we just accept backwards compatibility restrictions on these?
Or make the information available (and possibly tools) to allow downstreams to decide their policy on these.
For example, a file that said:
Asia/Rangoon Asia/Yangon rename 2005-11-26
Seems like a Good Idea. This is another way to handle obsolete IDs: Europe/Lisbon Portugal rename 2005-11-26 obsolete
Legally described mega-zones ----------------------------------------- The EU doesn't define "CET" or "WET", or even specify the names. So, since these don't describe "places keeping the same time since 1970", what exactly are they and why do we have them?
If done properly, they would only exist from the date that the rule was first established. As per the first of my threads, they are needed because CET does not have the same semantic meaning as Europe/Berlin.
Regions Non-region locations --------------------------- IDs for locations that are not region IDs. Each ID will have the same wall clock since 1970 as one of the region IDs.
Examples: Europe/Oslo, Europe/Amsterdam, Atlantic/Reykjavik
Consider: Can we write down a rule that covers which IDs are included here?
Or, put another way, partition the set of all zones into subsets, each of which have the same history since 1970. In each subset, one is what you've called an abstract region and the rest are non-region locations. The choice of the first is made based on our normal naming rules.
Kind of. The difficulty is that the ID of the abstract region is the *same* as the ID of the non-region location. In a theoretically pure solution, these two ID schemes are completely separate. ie. you would have a Region/Berlin region ID that represents time across the whole region with Europe/Berlin and Europe/Oslo location IDs following along (potentially with pre-1970 history). However what we actually have is a single merged ID scheme, where IDs for abstract regions, and IDs of locations where time is the same since 1970 exist together and are indistinguishable. I actually think the tzdb approach is just fine, so long as all the IDs (region and non-region locations) are equally supported. ie. it is not OK for region IDs to get things that non-region location IDs don't get.
And therefore when a new ID can be added to this set? If we can define a rule, then these can be split so rule-following IDs are in the main files and rule-breaking ones are in `backward` (although ideally they should be separate from the spelling changes).
Hang on, why should we ever add a new ID at all. My view is that we should *not* be adding new IDs. So long as we're talking about a post-1970 database, that is. In other words, the rule is "they stay for backwards compatibility reasons and no other".
Imagine Shetland broke away from the UK. Imagine this was undisputed and it joined the UN with everyone around the world happy to recognise it, thus it gets its own ISO code. But as a self-governing country it chooses to continue to follow the same timezone as London. tzdb would then be in the position that it has an ID representing a location in every European country except Shetland. The only justification being presented for this is that Shetland wasn't around 10 years ago when tzdb did have a one location per ISO code policy, thus it can't benefit from backwards compatibility as a justification for inclusion. I contend that this is an untenable position for tzdb to place itself in. (Substitute Shetland for Kosovo, and you get a scenario that is likely to happen in the next few years).
And IANA have long given up on that policy, which is why there are .gg and .scot.
The IANA rule is still working just fine. GG is an ISO code. And .scot is a generic tld not a country-code one. See column 2: https://www.iana.org/domains/root/db Stephen