[tz] Preparing to fork tzdb

[Guy Harris]

On Sep 23, 2021, at 5:41 AM, Steffen Nurpmeso <steffen at sdaoden.eu> wrote:

> Guy Harris wrote in
> <8C6BA6DA-AC7D-4FCE-97F0-1B277A981B55 at sonic.net>:
> ...
> |So one difference here appears to be that the pre-1970 data for Europe/O\
> |slo may be accurate while the pre-1970 data for America/Montreal may \
> |be inaccurate.
> 
> But isn't the drive to backzone going on for longer, yes hasn't it
> been introduced for exactly the purpose in 2014?

I.e., one to two years longer, given that America/Montreal was introduced in 2015 (as I believe I noted when I first brought up America/Montreal in this context).

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

> And what for?  This is not just "super correct" and "i give
> my users the full knowledge of the real thing, of anything", that
> is just broken.  It is anyway a programmer-only thing, maybe also
> a UNIX command line power user thing -- but to get it _really_
> right for _users_, you had to use ICU data and use their approach
> of time zones, that includes translation then also, does it?

macOS *does* include ICU, but the string "Oxnard" appears nowhere in CLDR as of cldr-28, so I suspect it uses more than just ICU data.

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

Anyway:

> Sorry for getting bold, but for one i really did not make that
> error (!), and then i also find it absurd to claim to offer
> a timezone interface that covers all the date and time data, and
> then to exclude backzone.

I think we need, as some have suggested, to figure out what to do about pre-1970 data.  I think that includes somehow making it clear that people who expect complete, accurate, and unchanging pre-1970 data are expecting something that

	1) is currently self-contradictory (Do you want "accurate" or do you want "unchanging"?  Some of the data we have is probably inaccurate, so that making it accurate will involve change!)

	2) would involve a lot of effort (sometimes it's even hard to get information about upcoming time changes from governments; finding historical information might be a lot harder, especially to people who aren't familiar with the language and culture of the location for which you're trying to get historical time information).

It also includes deciding whether to offer all the data by default (as in "not in backzone"), to provide a way to offer both sets of data separately, or whatever.

> On the other hand the announced release strategy felt offending to
> me.

I think that given the current level of controversy, the next release should be "2021a+Samoa and any other updates" rather than "current tip of the main branch", so that we get something out that includes the Samoa updates but doesn't include the controversial changes.