[tz] Some thoughts about the way forward
tgl at sss.pgh.pa.us
Thu Sep 23 21:39:28 UTC 2021
A modest proposal, if I may.
Let's take it as read that Paul is going to stick to his guns about
the May reorganization --- he's certainly shown no willingness to do
otherwise. (I do accept that there are valid reasons for that move,
even if I differ as to their importance.) What do we need to do to
mitigate the undesirable consequences of that reorganization?
After chewing on this for awhile, it seems to me that the really
fundamental undesirable consequence is going to be inconsistent
received versions of tzdb. Currently, the usage of backzone seems
to be quite negligible . But I fear it is certain that some
platforms will start using backzone, in order to placate users who
are negatively affected by the May changes. That will mean that
those platforms will start showing different results from platforms
that don't do that, for all zones in backzone (both old and new).
I rate this outcome as disastrous on multiple levels, not least
being the damage to the credibility of the tzdb project itself.
To avoid that, I already proposed  that we drop the links in
"backward" that are overwritten by backzone. This would have the
effect that a non-backzone build would not offer those zone names
at all, instead of presenting them as having the data content of some
other zone. This would eliminate the issue of different platforms
presenting different results for the "same" zone.
If we do that, it seems probable that instead of some platforms
adopting backzone, nearly all will, because otherwise their users
will moan about their favorite zone being gone. I therefore further
suggest that we make use of backzone be the default. Anybody who
wants a "lean and mean" build can leave it out --- but they'll be
presenting a clean subset of the data seen in the default build,
rather than data that is different and known to be less good in
This approach suggests that we make some adjustments in how we
think about things. I think we ought to rename backzone to
"extended" or something like that. We'd view tzdb as offering
a "base" set of zones that are considered in-scope per the rule
about different-since-1970, plus an "extended" set of zones that
are out-of-scope and are not maintained as carefully as the base.
(This really is just applying different terminology to the existing
understanding about how backzone is maintained.)
The primary advantage of doing it this way, rather than the way
we're handling backzone now, is that it's a lot clearer to end
users what the status of the extended zones is, and we're not
confusingly offering two different versions of those zones.
Assuming we make these changes before shipping git tip in its present
form, we could expect that users in zones affected by the May changes
would see no actual change in their TZ data. There would be a loss
of data stability for users in the zones that were moved to backzone
previously. I'm not terribly thrilled about that, but it seems like
the least amount of damage to the least amount of people, compared
to any other likely outcome. We could hopefully placate those users
by pointing out that (1) the new data, while likely not perfect, is
almost certainly a net improvement over what was shipped before,
and (2) this is effectively reverting these zones to their pre-2015
state. We'd thus be acknowledging that the original implementation
of backzone was a mistake, and undoing it with the least amount of
side-effects we can manage.
I shall now retire and wait to be shot at ...
regards, tom lane
More information about the tz