I second this, for the reasons stated by Stephen. Please revert. Thanks, Matt Johnson-Pint (Microsoft) On Wed, Jun 2, 2021, 6:03 PM Stephen Colebourne via tz <tz@iana.org> wrote:

This is a formal request to revert the recent patch to merge country timezones. I, and others, consider the patch to be utterly unacceptable. The patch causes meaningful harm to the status of tzdb, and will cause downstream projects significant pain to effectively revert the changes - amounting to an effective fork of the project.

Specifically, the patch merges the timezone history of completely separate countries, effectively wiping places like Norway and Sweden off the map to replace them by Germany. (Many other countries are also proposed to be wiped off the map).

The reversion MUST occur as soon as possible, and MUST be before the next tzdb release.

The tzdb coordinator is expected to operate by this charter: https://datatracker.ietf.org/doc/html/rfc6557

""" The TZ Coordinator is empowered to decide, as the designated expert, appropriate changes, but SHOULD take into account views expressed on the mailing list. ...

The criteria for updates to the database include the following:

1. New TZ names (e.g., locations) are only to be created when the scope of the region a name was envisioned to cover is no longer accurate.

2. In order to correct historical inaccuracies, a new TZ name MAY be added when it is necessary to indicate what was the consensus view at a given time and location. Such TZ names are usually not added when the inaccuracy was prior to 1970.

3. Changes to existing entries SHALL reflect the consensus on the ground in the region covered by that entry.

To be clear, the TZ Coordinator SHALL NOT set time zone policy for a region but use judgment and whatever available sources exist to assess what the average person on street would think the time actually is, or in case of historical corrections, was. """

I contend that to date, the TZ coordinator has not actively shown any serious willingness to accept that the proposed changes are unacceptable to a significant segment of tzdb users. As such, the coordinator has not taken into account the views of the mailing list.

I also contend that the "cleanup" being proposed is not within the charter of the project. Point 1 refers to new zones, thus is not applicable. Point 2 refers to correcting historical inaccuracies, yet it is clear that the proposed change *adds* historical inaccuracies. Point 3 refers to changes, but only in terms that reflect what people in the relevant location would have considered the time zone to have been, yet clearly the proposed change does not do that. No part of the charter permits the coordinator to willfully harm the database, nor to merge timezone regions, nor to increase the number of historical inaccuracies.

Justifications for the proposed change based on "consistency" or "politics" are not rooted in the charter of tzdb and should be considered null and void.

Given the above, I contend that the actions of the tzdb coordinator are in breach of the charter of the project, I therefore request that the changes are reverted immediately.

Stephen Colebourne

On 6/2/21 7:16 PM, Tom Lane via tz wrote:

I just experimented and confirmed that including backzone isn't nearly sufficient to bring the output data back to what it was previously.

It is sufficient, in the sense that if you included backzone before and still include it now, there are no changes to any timestamps (either pre- or post-1970). I've tested this. If you want only some of backzone but not all of it, we could add support for that (as I mentioned earlier). With that support, you could say "I want backzone to supply Europe/Stockholm", or "I want the zones that changed in 2021b to come from backzone". This should handle the use case you described.

On 2021-06-03 09:03:15 (+0800), Stephen Colebourne via tz wrote:

This is a formal request to revert the recent patch to merge country timezones. I, and others, consider the patch to be utterly unacceptable. The patch causes meaningful harm to the status of tzdb, and will cause downstream projects significant pain to effectively revert the changes - amounting to an effective fork of the project.

I don't consider the patch a breach of charter. Given the clear lack of consensus however, I agree that the patch should be reverted. While I believe the patch is within scope of the tzdb's stated purpose, we should be considerate of the many current, actual, real-world uses of tzdb beyond that scope. The best way forward would be to revert this patch and to discuss alternative ways to achieve its intent without alienating a substantial fraction of tzdb consumers. That discussion is a lot more likely to be productive without the (perceived) threat of a release with the contentious patch ending up in the wild. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises

On Thu, Jun 3, 2021 at 1:51 AM Jon Skeet via tz <tz@iana.org> wrote:

On Thu, 3 Jun 2021 at 02:57, Matt Johnson-Pint via tz <tz@iana.org> wrote:

...

I second this, for the reasons stated by Stephen. Please revert.

Thanks, Matt Johnson-Pint (Microsoft)

Agreed - while this clearly isn't yet a formal voting situation, I believe the change should be reverted.

Jon Skeet, Noda Time (.NET Date/Time library) lead developer

As the lead developer of [clock] (the date/time subsystem of the Tcl programming language)[1], I agree. Deleting tz names at this late time simply because neighbouring regions happen to have followed the same rules since 1970 (while also deleting the historical rules that made them different) is unacceptable. Failing that, I invite coordination with the maintainers of downstream projects to maintain a fork of tzdb rather than each of us having to do it independently. I see that PostgreSQL and Noda Time appear to be in the same boat. [1] This is not an official opinion of the Tcl Core Team. (Not yet. If an official opinion is needed, give me a couple of weeks to get a formal vote. I would be astonished if my colleagues disagree.) -- 73 de ke9tv/2, Kevin

Hi, I second this from Java i18n standpoint. It would be an incompatible change that would affect customers. Naoto On 6/2/21 6:03 PM, Stephen Colebourne via tz wrote:

This is a formal request to revert the recent patch to merge country timezones. I, and others, consider the patch to be utterly unacceptable. The patch causes meaningful harm to the status of tzdb, and will cause downstream projects significant pain to effectively revert the changes - amounting to an effective fork of the project.

Specifically, the patch merges the timezone history of completely separate countries, effectively wiping places like Norway and Sweden off the map to replace them by Germany. (Many other countries are also proposed to be wiped off the map).

The reversion MUST occur as soon as possible, and MUST be before the next tzdb release.

The tzdb coordinator is expected to operate by this charter: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc6557__;...

""" The TZ Coordinator is empowered to decide, as the designated expert, appropriate changes, but SHOULD take into account views expressed on the mailing list. ...

The criteria for updates to the database include the following:

1. New TZ names (e.g., locations) are only to be created when the scope of the region a name was envisioned to cover is no longer accurate.

2. In order to correct historical inaccuracies, a new TZ name MAY be added when it is necessary to indicate what was the consensus view at a given time and location. Such TZ names are usually not added when the inaccuracy was prior to 1970.

3. Changes to existing entries SHALL reflect the consensus on the ground in the region covered by that entry.

To be clear, the TZ Coordinator SHALL NOT set time zone policy for a region but use judgment and whatever available sources exist to assess what the average person on street would think the time actually is, or in case of historical corrections, was. """

I contend that to date, the TZ coordinator has not actively shown any serious willingness to accept that the proposed changes are unacceptable to a significant segment of tzdb users. As such, the coordinator has not taken into account the views of the mailing list.

I also contend that the "cleanup" being proposed is not within the charter of the project. Point 1 refers to new zones, thus is not applicable. Point 2 refers to correcting historical inaccuracies, yet it is clear that the proposed change *adds* historical inaccuracies. Point 3 refers to changes, but only in terms that reflect what people in the relevant location would have considered the time zone to have been, yet clearly the proposed change does not do that. No part of the charter permits the coordinator to willfully harm the database, nor to merge timezone regions, nor to increase the number of historical inaccuracies.

Justifications for the proposed change based on "consistency" or "politics" are not rooted in the charter of tzdb and should be considered null and void.

Given the above, I contend that the actions of the tzdb coordinator are in breach of the charter of the project, I therefore request that the changes are reverted immediately.

Stephen Colebourne

"Clive D.W. Feather via tz" <tz@iana.org> writes:

Since most zones in the database are amalgamations of pre-1970 zones, such "inaccuracies" have always been there and some people in the zone would have not said they were correct. So what? As far as I can see, the zones are accurate for all of their area post-1970 and part of their area pre-1970. This change doesn't alter that.

As far as I've understood, the loudest complaints are precisely because that isn't true. For example, the pre-1970 data for Europe/Stockholm would no longer be correct for any part of Sweden. My own concern is a shade more nuanced. Paul has stated that the tzdb results don't change as long as you were including backzone both before and after. (I haven't checked that, but I have no reason to doubt it.) However, the Postgres project is finding itself in a hard place precisely because we *didn't* adopt backzone. We reasoned that the default set of zones was the preferred thing and thus would be the most likely to remain stable. Now, not only is the default different (which perhaps we could live with), but there's no way at all to get the old default. That's not okay, and it seems to me to fly in the face of most understandings of software backwards compatibility, never mind any tzdb-specific rules. regards, tom lane

On 6/3/21 3:45 PM, David Patte via tz wrote:

My understanding is that the backzone data is complete and up-to-date for each zone that ever existed.

That's not quite right. First, some tzdb zones have gone missing over the years and nobody has taken the time to resurrect them for backzone. More importantly, "complete and up-to-date" suggests that backzone data is of high or comparable quality to the main database, which it's not: backzone contains lower-quality data that in some cases is surely wrong. (backzone does have some good entries, some bad, with little or indication of which is which.)

if all the backfiles do correctly link to the proposed main coalesced tz zones at their appropriate date/time, then that would work as well, but i would then work by accessing via the backfiles first. btw, for interest, the new main coalesced zone for New_York would include an area reaching from nearly Manitoba to the Atlantic, and include Toronto, Montreal, Ottawa and Quebec City , or about 1/2 of Canada's population.

On Jun 4, 2021, at 5:51 AM, Emily Crandall Fleischman via tz <tz@iana.org> wrote:

That's not true: Canada and the US had different DST rules until 1976, so their zones should remain distinct.

On Thu, 3 Jun 2021 at 22:07, David Patte via tz <tz@iana.org> wrote:

...

if all the backfiles do correctly link to the proposed main coalesced tz zones at their appropriate date/time, then that would work as well, but i would then work by accessing via the backfiles first.

btw, for interest, the new main coalesced zone for New_York would include an area reaching from nearly Manitoba to the Atlantic, and include Toronto, Montreal, Ottawa and Quebec City , or about 1/2 of Canada's population.

Yes, they should remain distinct, and they do remain distinct. Here's Paul's comment for the change: Merge timezones that are alike since 1970 * NEWS: Describe the change and its motivation. * Makefile (TZS_DEPS, check_tables): Depend on YDATA, not just PRIMARY_YDATA, since etcetera matters here. * africa (Africa/Abidjan, Ghana, Africa/Accra, Indian/Reunion) (Indian/Mahe): * antarctica (Indian/Kerguelen, Antarctica/DumontDUrville) (Antarctica/Syowa, Antarctica/Vostok): * asia (Asia/Brunei, Asia/Urumqi, NBorneo, Asia/Kuala_Lumpur) (Asia/Kuching, Indian/Maldives, Asia/Riyadh, Asia/Bangkok) (Asia/Dubai): * australasia (Indian/Christmas, Indian/Cocos, Pacific/Gambier) (Pacific/Tahiti, Pacific/Tarawa, Pacific/Majuro, Pacific/Chuuk) (Pacific/Pohnpei, Pacific/Palau, Pacific/Port_Moresby) (Pacific/Guadalcanal, Pacific/Funafuti, Pacific/Wake) (Pacific/Wallis): * europe (Denmark, Europe/Copenhagen, Iceland, Atlantic/Reykjavik) (Lux, Europe/Luxembourg, Europe/Monaco, Neth, Europe/Amsterdam) (Norway, Europe/Oslo, Europe/Stockholm): * northamerica (America/Blanc-Sablon, America/Atikokan) (America/Creston, Bahamas, America/Nassau): * southamerica (America/La_Paz, America/Curacao, America/Cayenne) (Atlantic/South_Georgia, America/Port_of_Spain): Move these duplicate Zone entries to 'backzone', and add backward-compatibility links in 'backward'. * checktab.awk: Don’t worry about links to Etc/*. * theory.html: Change examples to avoid merged-away zones. Remove references to SET, and to Amsterdam, Bangkok, Copenhagen and Port Moresby Mean Times. * zone.tab, zone1970.tab: Change 3rd column to avoid links in 'backward', which might not be present. * zone1970.tab: Merge lines to match the above changes. Note that America/Toronto is *not* one of the tzdb regions that disappears, so no, the new main coalesced zone for New_York does *not* include, for example, Toronto.