On Thu, 7 Oct 2021 at 07:08, Watson Ladd via tz <tz@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 use*. 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: https://github.com/eggert/tz/commit/6176aefe79e83ddb8f255849b85c149f34d46aba... https://mm.icann.org/pipermail/tz/2019-February/027571.html I believe the ISO rule should be reinstated (without threatening the primary rule that IDs are created based on timezone needs) Stephen