[tz] Classifying IDs
scolebourne at joda.org
Thu Oct 7 16:21:37 UTC 2021
On Thu, 7 Oct 2021 at 16:23, Clive D.W. Feather <clive at 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
> > 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
More information about the tz