"Mark Davis" <mark.davis@jtcsv.com> writes:
I'm inclined to recommend that we maintain stability as of a given date; that we never change an ID after that point.
1. Would there be any downside to such a policy?
Only if somebody builds the database without the "backwards" file, which lists the backwards-compatibility names. The default is to include "backwards", as it includes very common IDs like US/Pacific. I'd be surprised (but not astonished) if someone omitted it.
2. I was not able to find documentation as to whether there is a policy disallowing 'retired' IDs to be reused later for a different timezone.
It's never happened in the past, and I'd be surprised if it needed to happen in the future. Backwards compatibility is a big deal.
3. What was the reason for the change for Argentina?
San Juan needed a (new) entry, and "America/San_Juan" would have been too ambiguous: there are several other important San Juans in America.
Is this a one-off aberration, or can we expect America/Chicago to change to America/United States/Chicago, America/Vancouver to change to America/Canada/Vancouver, and so on down the line?
I wouldn't rule it out, but I think it unlikely in our lifetimes. If it happens, we'll put in backwards-compatibility links.
4. Are links expected to be definitional and stable? That is, if I ever have two IDs that are related by a link:
Link A B
Can it ever be the case in the future that the IDs A and B are "unlinked", and given different rules?
Yes. For example, currently Asia/Jerusalem and Asia/Tel_Aviv are links, but it's conceivable that political changes might cause them to use different rules. (Israeli politics are pretty strange sometimes.)
there are a small number of links that are "not final", meaning that what they link to, itself links to something else. While not formally an issue, it might be more convenient (and transparent) if these were put in a 'canonical' form.
Thanks for catching those; I'll do that in my next proposed patch.