I'm not entirely clear on the current status of the proposal. If most people are getting all the data from `backzone` anyway and the data is still being maintained in the repository, does this really alleviate the maintenance burden? Is the idea that the tzdb project will stop accepting patches to `backzone`, and thus these are frozen in amber? I suspect that if this is invisible to the end user, it will not keep people from reporting bugs or complaining about what they feel the key structure should be, and if anything it will increase bugs, because if they use a system that doesn't link in backzone, they'll be very confused about why previously valid keys are no longer valid. I'll note that I'm not against the proposal and I certainly don't think that it should be stopped because it would merge zones across country boundaries — I don't think there needs to be a notion of countries in the tzdb any more than there needs to be a notion of specific cities, I just want to know what we're supposed to be getting for the change. Personally, I agree with ado about maintaining the old funky pre-1970 zones (or at least keeping them present in the database as-is, indefinitely) for the purposes of stress-testing the capabilities of the tzdb. I make fairly extensive use of pre-1970 zones in my various TZif parsing libraries (e.g. Python's dateutil and zoneinfo) because that's where you get weird stuff like double daylight saving time, large swings in offset and fractional-minute offsets. At the end of the day, I think the main problem that this is addressing is that Paul wants to have some consistency in the rules so that he can point to the rule and say, "Here's the rule we're using, please tell us if there's a violation of /this rule/, otherwise we don't want to engage." But the problem is that we already have this for the most contentious stuff and it's not really enforced. The conversation instead goes, "Here's the rule we're using" and the follow up is, "That's a stupid rule, you should change it." then a bunch of people pile on in both sides and no time is saved. If that's going to happen anyway and every time anyone shows up and complains about the rules a dozen people are going to pile on saying, "We should change the zone names to non-human-readable alphanumeric keys" or "We should make one zone per country" /and it's not a violation of the rules of the list to do this/, I don't see the value in trying to break backwards compatibility in even small ways to be more consistent about these rules. Best, Paul On 5/29/21 10:34 PM, Philip Paeps via tz wrote:
On 2021-05-30 07:45:45 (+0800), Derick Rethans via tz wrote:
On 30 May 2021 00:29:28 BST, Paul Eggert via tz <tz@iana.org> wrote:
On 5/29/21 1:09 PM, John Hawkinson wrote:
There is a big difference between (1) "MERGING zones across modern countries" and (2) allowing to persist "zones [that] have crossed national boundaries for decades."
It's a big difference only to those closely following the history of tzdb. It's not a big difference to users.
Referencing https://datatracker.ietf.org/doc/html/rfc6557
Dear Paul, you've had a lot of push back to this change, as per the "Procedures for Maintaining the Time Zone Database" the TZ Coordinator "SHOULD take into account views expressed on the mailing list."
I would very much appreciate it if you'd at least listen to the feedback you've gotten on this change, and I'd argue that from what I've read, that this list is not OK with this proposed change.
One of the things I like a lot about the tzdb project is the spirited discussions we have on this mailing list about proposed changes.
Anyone who has been subscribed to the list for a while (or who spends some time reading the archives) will be aware that feedback is indeed taken into account.
This specific change has evolved a lot since its initial proposal.
It's also worth pointing out again to those unfamiliar with the way tzdb is usually distributed (e.g in operating systems distributions), that Paul's proposed change is largely invisible to most users. Most tzdb downstreams link in backzone. Data is merely being moved to a different place. It's not actually being removed.
Philip