[tz] Preparing to fork tzdb
brooks at edlmax.com
Wed Sep 22 21:49:20 UTC 2021
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:
>> I would point out, however, that zone1970.tab also contains the time zone *coordinates*.
> A "time zone" isn't a point, it's a set of points - and, at least if "time zone" means "tzdb region", it's a set of points not guaranteed to be simply connected, so it doesn't have a single curve that represents its border.
> As such, a "time zone" doesn't have a single coordinate pair, it has a whole bunch of coordinate pairs corresponding to its borders.
> All that zone.tab and zone1970.tab have is:
> # 2. Latitude and longitude of the timezone's principal location
> # in ISO 6709 sign-degrees-minutes-seconds format,
> # either ±DDMM±DDDMM or ±DDMMSS±DDDMMSS,
> # first latitude (+ is north), then longitude (+ is east).
> 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. But it is not accurate, and it does not define the "region".
It's merely an approximate guide.
>> This is different matter than country codes. In the work I'm doing the coordinates are important. They define the approximate default coordinates of time zones, and this is useful in a number of ways, indicating geographic distances between time zones and distinction of Northern and Southern hemispheres.
> But it's not useful for determining in which tzdb region an arbitrary coordinate pair belongs, which is also important to at least some Darwin-based OSes (macOS, iOS, iPadOS, watchOS - I can't speak for tvOS), as that's how their mechanism for automatically determining your machine's current tzdb region works.
> For that information, see
> which uses OpenStreetMap.
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.
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.
>> I think this has significance to the 'merging' controversy. "Europe/Oslo" is not the same time zone as "Europe/Berlin". They may have been using the same rule sets since 1970 resulting in identical local YMDhms representations but they have different time zone names (tags) and distinct coordinates. Oslo is not the same city as Berlin.
> San Francisco is not the same city as Los Angeles, but they're in the same tzdb region, so "city A is not the same city as city B" is insufficient region to have both Region/A and Region/B in the tzdb.
> Europe/Oslo and Europe/Berlin are, in 2021a and earlier releases, separate tzdb regions for historical reasons, both in the sense of "they had different rule sets prior to 1970" and in the sense of "the process of setting up tzdb regions happened to give them separate regions".
Right. I feel retaining them in the main files is the best approach.
> What Paul has noted is that there are cases where a single tzdb region covers locations not all of which have the same rules/offsets prior to 1970, and asks what's special about Norway and Germany.
> Two ways of changing that are 1) merging tzdb regions so that Europe/Oslo is a link to Europe/Berlin when using the default data and a separate tzdb region when using the backzone data and 2) splitting other zones so that pre-1970 data is available for them as well.
> Paul is going with 1) - and he notes that the backzone is still available and can be used.
Right. I think I'd have chosen to retain all time zones in the main well
known source files and providing new files that support filtering and/or
new features if that's the intention. But Paul has been more often right
than wrong, so I guess we'll see.
>> If time zone "Europe/Oslo" ever existed it still exists today. "Europe/Oslo" could adopt a new set of rules different from "Europe/Berlin" and its possible they might given the new elective rules being suggested by the EU.
> If tzdb region "Europe/Oslo" had never existed, Norway could adopt a new set of rules different from those in "Europe/Berlin", and a new "Europe/Oslo" region created.
> I.e., the *current* existence of a "Europe/Oslo" region is not at all necessary to allow a region that includes Oslo to adopt a new and different offset-from-UTC or new and different DST rules.
>> Olsen's original insight to use towns and cities to name time zones turns out to be extraordinarily useful. Whether or not "Europe/Oslo" is in Norway is entirely beside the point of local time in the "Europe/Oslo" time zone. Time zones really exist only in the time domain relative to the (special) "Etc/UTC" time zone. I'm sure most contributors to the tz list understand this, but there's a natural tendency equate a time zone with a location or place since this is where the general idea comes from to begin with. But I think tzdb must be vigilant to maintain this conceptual separation of time zone v.s. "place", especially in regard to politically named and claimed geographic boundaries such as Norway or Germany.
> 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.
> And there's no guarantee that tzdb region boundaries correspond exactly to national boundaries. (I live in one of the many countries that contain more than one tzdb region - and some of them differ for reasons other than how far they are from the IERS Reference Meridian, e.g. they differ base don whether they observe DST or not.)
Determining national boundaries and time zone regions is a difficult
problem, probably impossible in cases like disputed boarders. We all
understand tzdb cannot be perfect in all respects. It is, nonetheless,
the best available collection of time zone information, having
established itself as essentially the de facto standard defining civil
time. We really don't want to see it broken.
More information about the tz