[tz] Time zone selection

[Ángel González]

On 18/04/16 18:52, Paul Eggert wrote:
>
> For this reason I'm somewhat inclined to add one more hand-maintained 
> table, zone-now.tab, which is like zone-1970.tab except using a cutoff 
> of "now" (a deliberatly moving target) instead of a cutoff of 1970. 
> That should be good enough for applications that don't need historical 
> time stamps, and will be easier to automate and CLDRize.
>
I don't think such dynamic target would be appropiate. It wouldn't even 
be correct for storing the meeting you had last week.
I agree a file like zone-2000.tab or zone-2010.tab would be useful 
because the actual set of applicable zones will actually be smaller. 
However, I am wary of hand-maintaining it. It seems automatable with "a 
bit of help" for breaking ties.


> How does the automated procedure choose the ID of the merged region? 
> It should be America/Denver, as that has the greatest population, but 
> how is the population recorded and what happens as population changes? 
Why not use the oldest ID for the merged region? (oldest as in earlier 
to have been introduced in the Olson db).
The other names should be aliases, anyway.

> Furthermore, how does the automated procedure derive the comment for 
> the merged region? 
Not ideal, but with a few linguistic rules, it could combine the 
comments into something acceptable.

> And how would CLDR translate this automatically-derived comment?
Periodically syncronize the translations? It's not that it would be 
different with a manually-maintained file.

Best