[tz] Preparing to fork tzdb
gharris at sonic.net
Wed Sep 22 23:18:22 UTC 2021
On Sep 22, 2021, at 3:49 PM, Brooks Harris <brooks at edlmax.com> wrote:
> 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 as "America/New_York".
In what fashion does having 111 E 1st Street, Los Angeles be the "principal location" for America/Los_Angeles make that principal location different from another time zone, but having 2800 E Observatory Road, Los Angeles be the "principal location" for America/Los_Angeles not do so?
(Did 111 E 1st Street, Los Angeles appear in Rebel Without a Cause, Back to the Future I and II, and La La Land? 2800 E Observatory Road, Los Angeles did.)
>>> 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".
So in what circumstances is the current tzdb region currently used, in the real world, to determine your location?
And in what fashion is "somewhere in Los Angeles" a better location indication for where I am right now than "I don't know"? (The fact that the city I'm in has the same initials as Los Angeles doesn't count; as noted, it's over 400 km away from Los Angeles.)
>>>> 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.
The statement to which you responded iss "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."
An application that's using tzdb regions other than the one you're in will not, when using those regions, be affected by whether the zone you're in is Europe/Oslo or Europe/Berlin. The boundaries of the regions matter only if the application is choosing the other locations to use by taking a location on Earth and determining, using those boundaries, which region that location is in.
The difference between Europe/Oslo and Europe/Berlin will matter to an application dealing with pre-1970 times even if the region names are coming from a user interface or a configuration file; in the latter case, the boundaries don't matter to the application, although they'd matter to whoever or whatever entered those region names.
More information about the tz