[tz] Preparing to fork tzdb

[Guy Harris]

On Sep 23, 2021, at 3:26 PM, Steffen Nurpmeso <steffen at sdaoden.eu> wrote:

> Guy Harris wrote in
> <B97CABBF-BFEA-4CE5-9D05-9663170ABBE0 at sonic.net>:
> |On Sep 23, 2021, at 5:41 AM, Steffen Nurpmeso <steffen at sdaoden.eu> wrote
> 
> 
> |> Ever since i am on this ML it was discussed often to possibly
> |> replace the identifiers with anonymized strings, i wonder how
> |> anyone could create an interface where one name maps to another
> |> name.
> |
> |If I open up System Preferences on my machine, select the "Date and \
> |Time" entry, select the "Time Zone" tab, enable editing via a couple \
> |of steps, and type "Oxnard" into the "Closest City" box, under the \
> |hood it maps "Oxnard, CA" to "America/Los_Angeles", setting the current \
> |system tzdb region to the latter.  (And then I go back to "figure it \
> |out automatically based on where I'm currently located", but I digress....)
> |
> |Is that what you mean by "one name maps to another name"?  There's \
> |no "America/Oxnard", so it needs to figure out that Oxnard is in the \
> |tzdb region that's named "America/Los_Angeles".
> 
> This is malicous hairsplitting for nothing.

No, it's attempting to determine what you mean by "an interface where one name maps to another name".  It sounds as if you are not referring to interfaces where a city name maps to an identifier for the tzdb region in which that city resides, in which case I wonder how anyone could wonder how anyone could create such an interface, given that, at minimum, they exist in macOS and Ubuntu.

So what *do* you mean here.

> If a programming interface gives you one TZ name for another TZ
> name where both effectively indistinguishable select the same
> data.

OK, so is *that* the type of mapping to which you're referring?  Mapping tzids to other tzids (which is *not* what I was referring to when describing the macOS time zone selector)?  That's different from "[replacing] the identifiers with anonymized strings".

> |
> |> You know, as a human german speaking being i would _never_ assume
> |> Europe/Vienna and do "$ TZ=Europe/Vienna date" really, that is
> |> a nerd assumption.  Maybe "$ date --country=AUstrIA" or
> |> "$ date --city Würzburg" or "$ date --state Baden-Württemberg",
> |> and i only write this for case-messing out-of-ASCII.
> |
> |Sounds good.  That would require data of the sort that macOS uses; \
> |could OpenStreetMaps data be used?
> 
> Well _i_ do not think that sounds good, i think reality is you go
> to a mega companies app store, download one, and then input or
> even speak a name.

What doesn't sound good - using OpenStreetMaps?  Or allowing "date --country=AUstrIA", "date --city Würzburg", or "--state Baden-Württemberg"?

"date --country=Canada" doesn't work, for obvious reasons (the same applies to "United States", "Australia", "Russia", etc.).

"date --state=Arizona" doesn't work, because you aren't indicating which part of Arizona you're in.

But those can print an error message.

> My personal opinion is that data should not be splitted at all.
> Instead tooling should be used to cut where the line, if any, is
> drawn, the make file is capable of doing this.  Without being able
> to quote now, IANA TZ is supposed to offer post-1970 data by
> default.

Preferably with a big red "THIS IS NOT GUARANTEED TO BE CORRECT AND IS SUBJECT TO CHANGE OVER TIME AS A RESULT OF ATTEMPTS TO MAKE IT MORE CORRECT" warning.  Those who find those caveats unacceptable are more than welcome to solve the problem themselves.

> It is just sad that for black and other coloured noone spoke up
> against splitting to backzone, but suddenly it is shaking.

Which is part of the point that Paul was making - why is Europe/Oslo currently not in backzone but Africa/Asmara is currently in backzone?

There is at least one wypipo region where data was moved to backzone, America/Montreal; I don't know whether that received more pushback than, say, the movement of Africa/Asmara to backzone.

> Given the length of the thread, maybe your way is the best.

"My" way?  As I indicated in another message, I have no strongly-held ideas about whether pre-1970 data should be relegated to backzone.  (And I've also indicated that I think that, *regardless* of the merits or demerits of moving Europe/Oslo to backzone, the right thing to do for 2021b is not to move anything to backzone, just because it's proven, at least to my eyes, to be sufficiently controversial that it shouldn't be done *right now*.)

I also haven't weighed in on the way to handle backzone in the build process if we keep it around and move more stuff to it over time.