[tz] On ISO country for timezones (Re: Classifying IDs)

[Fred Gleason]

On Oct 7, 2021, at 11:47, dpatte via tz <tz at iana.org> wrote:

> Are we going to have two tz databases, or just one. That is the question here.

This does appear to be one of the fundamental questions at this point. There are differences in the characteristics of the data pre- and post-1970. Post-1970, the data is rigorously researched and scoped to apply to a precise, quantifiable entity (often a geographical region, but with a few ‘meta-regions’ like ‘UTC’ and ‘EST5EDT’ thrown in). OTOH, pre-1970 data is characterized by a variable quality of research (ranging from quite rigorous to approaching outright guessing), with the precise scope of applicability that often seems to amount to little more than ¯\_(ツ)_/¯.

Simply on the basis of the amount of discussion that took place in the few weeks leading up to the release of 2021b, these differences are large enough that I think there’d be real merit to instituting some sort of formal partitioning between the two data sets. Though of course it’d actually be a decision for downstream maintainers, I think a strong argument could be made that Operating System-level services should contain only post-1970 data. If you are a user who cares about data pre-1970, then I think you really need to be accessing the TZDB direct through an appropriate API rather than relying on whatever the OS maintainers have chosen to package. I envision two distinct ‘products’ here: one that I’ll call ’TZ Main’, which would be strictly limited to timestamps at or before 1970-01-01 00:00:00+00:00, and ’TZ Historical’, which would consist of ’TZ Main’ + whatever additional data pre-1970 that exists.

While this sort of partitioning does exist in the current practice of supporting things like ‘backzone’, there are some real downsides to that approach; the primary one being the relative obscurity of such options to many users, particularly those who don’t use TZ’s makefile in their workflow. I’m wondering if it might make sense to extend such partitioning to the point where there would be two distinct data tarballs generated for each release; one for each ‘product'. That would make it crystal clear to everyone exactly what it is that they are getting.

The primary downside here of course would be lots of data churn and extra work during the transition, especially for those downstream users who need historical data. In the long terms however, it would surely aid the process of ensuring that the alarm clock on a bajillion mobile devices consistently go off at the right time. 

Cheers!


|---------------------------------------------------------------------|
| Frederick F. Gleason, Jr. |             Chief Developer             |
|                           |             Paravel Systems             |
|---------------------------------------------------------------------|
|         A room without books is like a body without a soul.         |
|                                                                     |
|                                                         -- Cicero   |
|---------------------------------------------------------------------|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20211007/b5c6a34b/attachment.html>