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 [1]. 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 [2] 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 some cases. 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 [1] https://mm.icann.org/pipermail/tz/2021-September/030572.html [2] https://mm.icann.org/pipermail/tz/2021-September/030632.html