[tz] Pre-1970 data

[Paul Eggert]

On 10/18/21 06:07, Stephen Colebourne via tz wrote:
> What tzdb previously offered was a set of IDs,
> based on a simple rule - "ID as needed for post-1970 data, with at
> least one per ISO country". Full history was available for each of
> these (whether accurate or not).

That wasn't ever the case. For example, there was never full history 
(accurate or not) for San Marino. We shouldn't base our analysis on the 
idea that we formerly had at least one Zone per ISO country, as we never 
had an ironclad rule like that and we did just fine without any such rule.

There's no *timekeeping* reason to require a Zone for every ISO country. 
Adding such a requirement would complicate maintenance. It would add a 
significant amount of likely-bogus data, as witness the recent 
discussion about the likely-bogus data for Bamako that's in 'backzone'. 
And it would increase the role of politics particularly as new countries 
emerge, and politics is something we should avoid as much as possible.

These downsides of a one-Zone-per-country rule may not appear to be all 
that serious to people who are not actively maintaining the database, 
but as the primary maintainer of a database that I would like to be as 
accurate as possible, I would object to adding distracting and 
error-prone makework like that to my volunteer workload.


> tzdb really needs to offer one
> standard view of data, not command line flags that allow different
> views. If downstream projects end up with different views of the data,
> it makes tzdb a much less reliable source

Unfortunately it's impossible in any voluntary project to assure 
complete uniformity on all platforms. It's been reasonably common for 
various downstream platforms to have their own wrinkles (their own names 
or zones, or they truncate data to certain years, or they have only a 
subset of the names, or they don't support some tzdata feature, or 
whatever) and the sky has not fallen as a result. Although we can 
attempt to lessen unnecessary differences, there are sometimes good 
reasons to give users different views of available data and I doubt 
whether it would be a good idea to prohibit variances like these, even 
in the long run.


What I am sensing from your proposal, as well as from some of the 
followup comments, is a need to further clarify exactly what the tzdb 
project's interfaces are. Some downstream uses have relied on internal 
details of the database that have never been promised to be stable, and 
this has caused friction when these details change. It would be helpful, 
I think, to make the boundaries clearer.