[tz] Pre-1970 data
Paul Eggert
eggert at cs.ucla.edu
Wed Nov 3 22:40:31 UTC 2021
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.
More information about the tz
mailing list