Question on id stability

[Paul Eggert]

"Mark Davis" <mark.davis at 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.