[tz] Preparing to fork tzdb

[Guy Harris]

On Sep 22, 2021, at 2:49 PM, Brooks Harris <brooks at edlmax.com> wrote:

> On 2021-09-22 4:41 PM, Guy Harris wrote:
>> On Sep 22, 2021, at 11:32 AM, Brooks Harris via tz <tz at iana.org> wrote:
>> 
>> The "principal location" is, presumably, the city or other location that gives the region its name; I live about 480 km from the "principal location" of the tzdb region I'm in.
> Yes, all true. I think that "principal location" is helpful as a default.

How so?  I'm over 400 km from my tzdb region's "principal location".

And what's special about 111 E 1st Street, Los Angeles, that makes it more "principal" than, for example, 2800 E Observatory Road, Los Angeles?

> Yes, true. I don't believe providing information for automatic time zone detection is tzdb's responsibility. Its an application feature downstream from tzdb. But I think that "principal location" is a helpful starting point in some circumstances.

In what circumstances are those?

> Part of my observation is that the zone1970.tab contains *both* country code and coordinates, which couples the tz time zones to the country creating some part of the difficulty of avoiding politics as much as possible. Maybe ideally there should have been a 'coordinates' file and a 'country' file. I'm not suggesting this should change, only pointing out this is where tzdb got connected to country politics.

One question is "should zone.tab and zone1970.tab officially even be considered part of the tzdb, or are they just "interesting additional data"?

>> Although, when it comes to determining whether to use Europe/Berlin or Europe/Oslo on your laptop/tablet/phone/watch, the geographic boundaries of Europe/Berlin, Europe/Oslo, etc. *do* matter.
> Yes, that's part of my concern about merging Europe/Oslo with Europe/Berlin.

Right now, the only difference that would make to the mobile machine in question is in applications that handle pre-1970 time stamps in the tzdb region in which they're currently located.

For *those* applications, they would require a set of tzdb files that include backzone if they are to handle pre-1970 time stamps while the user is in, for example, Asmara.  If they include backzone, they will be unaffected by the merger.

Those applications might also require some *additional* pre-1970 region splits in the future.