[tz] Preparing to fork tzdb
Paul Eggert
eggert at cs.ucla.edu
Tue Sep 21 19:24:47 UTC 2021
On 9/20/21 1:56 PM, Stephen Colebourne via tz wrote:
> where we
> disagree is the need to nuke what we have now as a first step.
Again, nothing has been nuked. Some data have merely moved from one
place to another.
> As I've said before, there are only two equitable solutions for the
> default tzdb files (ie minus backzone). Either they contain full
> history for every ISO country (even if that history is inaccurate), or
> they contain no pre-1970 data at all.
There's no need to involve ISO countries, as far as equity is concerned.
Suppose someone argued that there should be a full timezone history for
every state and province and city in the world, and that otherwise there
should be no pre-1970 data at all. Such an argument would be equally
invalid, even though these smaller entities were (and in many cases
still are) the governmental agencies responsible for setting civil-time
rules.
For proper timekeeping we needn't model every governmental agency
involved in timekeeping; all we need to do is model the timekeeping.
Requiring involvement of countries complicates the TZ database for
political reasons, not for timekeeping reasons. As such, it complicates
maintenance, mostly due to political hassles. We do better by avoiding
political entanglements when possible.
> Expecting downstream projects to change their build systems with no
> notice to solve an artificially created crisis isn't good project
> management.
Yes, it would be better if we came to a consensus and did not have to
fork the repository or fork the project in some other way. Any such fork
will require some sort of build-system changes for those who doesn't
take the default approach.
As I've tried to make clear in my recent emails, although the proposed
fork is technically feasible (and doesn't even need to rely on a copied
repository), it's not a good idea. This is not merely because of the
hassle of configuring after a fork; it's because merely going back to
2021a's setup is not something we can or should do, on equity grounds.
More information about the tz
mailing list