[tz] On ISO country for timezones (Re: Classifying IDs)

Stephen Colebourne scolebourne at joda.org
Thu Oct 7 11:16:50 UTC 2021

On Thu, 7 Oct 2021 at 07:08, Watson Ladd via tz <tz at iana.org> wrote:
> Backwards compatibility is a very strong justification when systems
> are using identifiers to store data. Consumers of tzdata need to
> understand what is and is not backwards compatible.

I agree with backwards compatibility. The primary concern here is
whether an ID is considered deprecated or not.

> Do you have actual applications that broke/ would have broken because
> these are not zones?

This looks like a misunderstanding. At no point in the OP did I talk
about Zones vs Links. I only talked about IDs.

What I'm trying to do is:
- get agreement that tzdb has IDs beyond those needed for the abstract
region system
- that those IDs are in widespread use
- that those IDs should be considered a fully supported aspect of tzdb
because of their widespread use
- that there is a clear rule expressing which IDs are fully supported
and which are deprecated.

I don't think the first two are seriously doubted, it is the latter
two where the issues are.

> You need to justify this rule with respect to timezone data. The space
> of concerns is entirely different. Time zones are far more aligned
> with commercial relationships across borders than they are with
> political boundaries: that's why Idaho, Indiana, and Australia look
> the way they do. A lot of timezone splits coincide with changes to
> political boundaries, making the utility of country by country zones
> dubious: South Sudan, East Timor, etc.

None of that is in dispute. IDs will continue to exist and be created
driven by timezone needs, not by countries. The question is how do we
justify the IDs that we *already have*, and that are in *widespread

Think of it as overlapping concerns. There is a minimal set of IDs
that are needed for timezone reasons (abstract regions like
Europe/Berlin and Africa/Abidjan). And there is an overlapping set of
IDs that have existed for a very long time, are very widely used, but
are considered by some to be deprecated. A typical downstream user
*cannot tell the difference* between the two types of ID - they both
look and act exactly the same.

What I'm trying to do is bring that downstream user point of view back to tzdb.

ISO countries happen to be the best fit to describe the set of IDs
that I'm arguing should be fully supported. That is because it used to
be the rule. The change to remove ISO countries happened as recently
as February 2019:
I believe the ISO rule should be reinstated (without threatening the
primary rule that IDs are created based on timezone needs)


More information about the tz mailing list