[tz] Preparing to fork tzdb
brooks at edlmax.com
Wed Sep 22 22:49:56 UTC 2021
On 2021-09-22 6:18 PM, Guy Harris wrote:
> 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?
It makes its "principal location" different than another time zone, such
>> 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?
Say we have an interchange format that includes:
a) tz time zone tag
b) local tz date and time
c) coordinate field
The idea here is that some devices will be able to support accurate
coordinates from GPS, like a truck, car, or smart phone. But many
devices will not have GPS or other means of determining location. So,
the tzdb supplied "principal location" coordinates are a much better
default than zero-zero or "unknown".
>> 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"?
I agree that's worth considering. One approach that could dispose of
some of the controversy in one stroke would be to simply delete those
files. But, once something is plugged in you can't turn it off. I expect
such a suggestion would be met with some derision.
>>> 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.
An application may be calculating times in some other or several other
time zones. Its not just where its 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.
Yes, there will be ongoing changes no doubt. Tzdb is not easy.
More information about the tz