[tz] Proposal: Sections for different kinds of backward links
scolebourne at joda.org
Thu Nov 18 02:29:19 UTC 2021
As a reminder, you said "These groupings should provide useful
I've provided feedback that the categories are not helpful to me as a
downstream consumer - Having "Singapore" (an obsolete ID) in `primary`
really isn't useful info and you might as well not bother with the
change. The whole point is to provide a way to prune obsolete IDs like
If you want downstream consumers to have useful info from this change
you would need a list of all obsolete IDs, all posixish IDs and the
minimal set of primary IDs (ie. excluding spelling and obsolete
On Wed, 17 Nov 2021 at 20:43, Paul Eggert <eggert at cs.ucla.edu> wrote:
> On 11/17/21 02:03, Stephen Colebourne via tz wrote:
> > On Tue, 16 Nov 2021 at 18:20, Paul Eggert <eggert at cs.ucla.edu> wrote:
> >> I was thinking that one can look in zone.tab. If the spelling is there
> >> it's "preferred" otherwise it's not.
> > That makes these categories less useful. It involves a downstream
> > consumer processing zone.tab and cross-checking it. It also doesn't
> > handle the case where there is a spelling change for an ID that is not
> > listed in zone.tab.
> You're right that it's a bit more work downstream, and that it doesn't
> handle arbitrary questions about which names are preferred to which
> other names (for example, it doesn't establish a total order on names).
> However, it does seem to suffice for the specific problem you mentioned
> about backwards compatibility (one name per ISO country), and it has the
> advantage of not burdening the upstream maintenance process with even
> more political questions.
> > It is not at all clear why you would want the `primary` category to
> > contain both Asia/Kolkata and Asia/Calcutta.
> The idea was that the 'primary' category would be about the timestamps
> (where Asia/Kolkata and Asia/Calcutta are identical), not about the
> metadata (where people might disagree about how to spell the city's
> name). This would help insulate tzdb from political issues. Although we
> cannot insulate tzdb completely from politics, when it's easy to do so
> then we should do it.
More information about the tz