On 2021-03-25 20:31, Dimitri John Ledkov via tz wrote:
On Fri, 26 Mar 2021 at 01:55, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 3/25/21 5:46 PM, Dimitri John Ledkov via tz wrote:
I'm not quite sure what it means to have "CZ,SK" dual code for Europe/Prague.
It means that Europe/Prague covers some territory in both CZ (Czech Republic) and SK (Slovakia). This is mentioned in the comments at the start of zone1970.tab.
I see. In that case it is accurate. Ditto the set of codes for Europe/Simferopol that timezone does cover some territory in both RU & UA.
is it just an oversight that Europe/Bratislava is not listed in the zone1970.tab file
No, it's intended. The Europe/Bratislava link is present for backward compatibility; it's no longer really needed for tzdb settings since Slovakia's clocks have agreed with Europe/Prague's since 1970.
It would be more helpful to return CS code for years 1918–1939 and 1945–1992
Not really as that wouldn't be historically accurate, and even if it were accurate it would cause more political hassles than we already have (people care a lot about history for some reason :-).
zone1970 is not helpful, especially since it's alphabetical sort
Is this referring to some existing Ubuntu-based software that uses zone.tab and that requires alphabetical sorting? I'd be interested to know what software has this problem. It might be possible to work around problems in this area, but I'd need to know what the problems actually are.
I think the problem is that it is misused as one-to-one territory/boundary mapping, when (a) that's not what it defines (b) it's not boundary.
will not yield appropriate country code for Europe/Simferopol pre/post 2014 time periods
That's OK, as zone1970.tab is not a historical database. It's intended only for people who are setting their timezones today.
Are there plans to add a new zone.tab format that provides UNTIL field?
No, for the reasons mentioned above.
In hindsight the zone.tab file was a mistake because it inspires too many political controversies. zone1970.tab is somewhat better, but even it goes beyond what a timezone database needs to do.
These two files were intended only as aids to user interfaces to selecting timezones. Modern timezone-selection user interfaces typically use boundaries[1] rather than these files, so perhaps someday we can remove both of them. Any continuing political controversy about them will likely accelerate the process of their removal.
[1] https://data.iana.org/time-zones/tz-link.html#boundaries
I'll need to double check things, I think we are self-generating approximate boundaries based on zone.tab instead of using a pre-existing / more accurate boundary map.
I believe that the previously available sources for that information are no longer being updated, and time zone sites are using their own approaches, which may include outdated data. Probably better to map gazetteer locations to zones using approximate boundaries or older data, and tweak any discrepancies. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]