[tz] [PATCH] Update Crimea country codes in line with UN A/RES/73/263

Dimitri John Ledkov xnox at ubuntu.com
Fri Mar 26 02:31:18 UTC 2021

On Fri, 26 Mar 2021 at 01:55, Paul Eggert <eggert at 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 &

> > 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.



More information about the tz mailing list