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