Paul Eggert's rationale is informative https://mm.icann.org/pipermail/tz/2021-September/030764.html But I think there are a few more things to say. The aim of merging timezones was to avoid political issues and to reduce the maintenance burden. It seems to me that it has failed to achieve those goals. There have been several very long discussions on the topic, and the recent arguments are making exactly the same points as were made in 2013. So I think the changes have increased the amount of political discussion and controversy on the tz list, not reduced it. https://mm.icann.org/pipermail/tz/2013-May/thread.html https://mm.icann.org/pipermail/tz/2013-August/thread.html https://mm.icann.org/pipermail/tz/2013-September/thread.html Paul says in his rationale that it was a lot of extra work, and in other messages he said that he has found it hard to keep up with the discussions. So merging timezones has increased the maintenance burden, not reduced it. I have identified two policy changes that caused this argument. In 2013, Paul Eggert started a new policy of merging timezones that are the same since 1970. As far as I can tell, no-one wanted this other than Paul. This merging policy was applied first to places with small populations, and (because of alphabetical order) to Africa, which is not well-represented by the people on the TZ list. Some of the merges also ignored the guideline that each country should have at least one timezone to call its own. The other policy change was to drop the guideline that each country should have at least one timezone. This change occurred in 2019, buried at the end of a very long discussion about Vietnam, and presented as a fait accompli. https://mm.icann.org/pipermail/tz/2019-February/027602.html This was after a great deal of discussion about the need to retain country information in the tz database, back in 2013 when these changes started. As I understand it, the equity / fairness issue is that the timezone merges were implemented in an unfair manner, affecting Africa (since 2014, against the guidelines as written at the time) but not Europe. So although Paul says the merges worked without significant incident, they did in fact cause a political complaint - exactly what the merges were supposed to avoid. The current argument was triggered by the question of whether this fairness issue should be addressed by undoing the data loss in the compiled tz files that caused the complaint, or by imposing the data loss more strictly. I think the way to fix this is to revert both policy changes, and revert all the timezone merges. Tony. -- f.anthony.n.finch <dot@dotat.at> https://dotat.at/ Lundy, Fastnet, Irish Sea: Northwest 4 to 6, backing southwest 5 to 7, perhaps gale 8 later. Slight or moderate until later in Irish Sea and Lundy, otherwise moderate or rough. Rain or showers. Good, occasionally poor.
On 2021-09-29 19:20:36 (+0800), Tony Finch via tz wrote:
I have identified two policy changes that caused this argument.
[...]
I think the way to fix this is to revert both policy changes, and revert all the timezone merges.
I agree with this. Moreover, I wonder if we should not also consider merging the contents of backzone back into the main data files. The backzone file was introduced in 2014 as a home for out-of-scope and/or poorly-sourced data. Instead of providing build options to increase the size of the tzdata distribution, I believe we should go the other way. Contemporary systems are by default "large". Developers working on smaller embedded devices are accustomed to making changes to reduce the footprint of the data/code they consume. Note that I am not suggesting that we step away from our long-standing policy that timestamps before 1970 are out of scope. My suggestion is that we gain nothing from putting out-of-scope data into a separate file. Our documentation of the policy suffices. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Thanks to Tony Finch's evidence, I'm now realizing two key points that were unclear to me as a follower of the project since only 2018. 1) In 2013, a long-adopted policy of having a Zone for each ISO 3166 country was abandoned at Paul's discretion [1], a decision that was disputed at the time and didn't seem to have much support from others. 2) Paul's initial changes in 2013-2014 to unify zones that don't differ post-1970, starting alphabetically with African Zones, *were indeed highly disputed at the time.* In particular, Stephen Colebourne, who's been the most vocal opponent of the current changes, laid out the exact same justifications back then! As did others who are commenting today. For examples, see threads [2-8]. If anyone is reading Paul's current justifications for these changes, one comes away with the impression that people are only complaining now that it's European countries' Zones being merged rather than African countries' Zones. Paul himself wrote in his justification [9]:
It's a bad look for us that so much concern about Norway and Sweden has appeared on this mailing list, even though hardly anybody seems to have cared about Angola and Congo. It'll be an even worse look if we ignore this issue weeks, months or even years after it's been made clear to us.
This description is not only demonstrably false, as the above examples show, but indelicate and incendiary given the context -- namely, that Paul is invoking racial and national bias to motivate the changes this time. In another thread recently Paul wrote that "the equity issue has broadened and is now visible outside our little community" [10]. So why give this false and misleading impression of people's motives to those outside our little community? As further context for my remarks, I'd like to add that, although I'm relatively new to the project, I have tremendous respect for Paul's contributions to it over the decades. His long-standing practice of providing insightful history, context, links, and pop culture examples throughout the project files and this mailing list is directly responsible for my own fascination with tzdb. Best, Scott Kilpatrick https://typesandtimes.net [1] https://github.com/eggert/tz/commit/d3b025adb25554ee10b986850371e573df92733e [2] https://mm.icann.org/pipermail/tz/2013-August/019601.html [3] https://mm.icann.org/pipermail/tz/2013-August/019593.html [4] https://mm.icann.org/pipermail/tz/2013-August/019646.html [5] https://mm.icann.org/pipermail/tz/2013-August/019674.html [6] https://mm.icann.org/pipermail/tz/2014-July/021170.html [7] https://mm.icann.org/pipermail/tz/2014-July/021248.html [8] https://mm.icann.org/pipermail/tz/2014-August/021288.html [9] https://mm.icann.org/pipermail/tz/2021-September/030764.html [10] https://mm.icann.org/pipermail/tz/2021-September/030742.html On Wed, Sep 29, 2021 at 8:22 AM Philip Paeps via tz <tz@iana.org> wrote:
On 2021-09-29 19:20:36 (+0800), Tony Finch via tz wrote:
I have identified two policy changes that caused this argument.
[...]
I think the way to fix this is to revert both policy changes, and revert all the timezone merges.
I agree with this.
Moreover, I wonder if we should not also consider merging the contents of backzone back into the main data files. The backzone file was introduced in 2014 as a home for out-of-scope and/or poorly-sourced data.
Instead of providing build options to increase the size of the tzdata distribution, I believe we should go the other way. Contemporary systems are by default "large". Developers working on smaller embedded devices are accustomed to making changes to reduce the footprint of the data/code they consume.
Note that I am not suggesting that we step away from our long-standing policy that timestamps before 1970 are out of scope. My suggestion is that we gain nothing from putting out-of-scope data into a separate file. Our documentation of the policy suffices.
Philip
-- Philip Paeps Senior Reality Engineer Alternative Enterprises
I just want to point something out: On 29.09.21 18:19, Scott Kilpatrick via tz wrote:
1) In 2013, a long-adopted policy of having a Zone for each ISO 3166 country was abandoned at Paul's discretion [1], a decision that was disputed at the time and didn't seem to have much support from others.
Members of this list do not have to comment on anything, and generally don't. This list is usually very quiet. Paul makes all sorts of changes without much comment. If he didn't, there would be almost no updates, and the database would be out of sync, and people would be upset about that. The role of the TZ Coordinator is one of designated expert. He can and does seek views of the community, but the process laid out in 6557 expects him to use his judgment and not to only rely on that consensus. We wrote it that way because to do otherwise would require more work from this group of volunteers. And so it is misleading to say that Paul moved forward without much support. He is SUPPOSED to move forward without much support, though he should take great care when he does. Eliot
On 9/29/21 4:20 AM, Tony Finch via tz wrote:
The aim of merging timezones was to avoid political issues and to reduce the maintenance burden. It seems to me that it has failed to achieve those goals.
Thanks for your comments and concerns. Although the recent contretemps has been a setback, it's been less of a maintenance burden (to me at least) than other things that merging timestamps helped forestall. The Kosovo business earlier this year is an example. Political issues have the real potential to kill the project, and that hazard far outweighs all the relatively-minor technical issues involved in merging Zones. Admittedly there has not been unanimous agreement about merging Zones, and Stephen has objected since the beginning. And there is inevitably a conflict between the exceedingly few users who want lots of reliable pre-1970 data and yours truly, a volunteer maintainer who cannot satisfy these users' desires and who needs to draw the line somewhere, fairly. That being said, pre-1970 timestamps are an area where the long-term maintenance burden is very real and the overall end-user benefit is exceedingly tiny, even negative. So it's been an easy call for me so far.
I absolutely disagree with the claim that end-user benefit of pre-1970 data is exceedingly tiny. *pre-1970 time data are extremely important for hundreds of authors and millions of users of astrological software.* Whatever one may think of astrology, it is a fact that at was astrologers like Thomas Shanks and others who collected extensive historical time zone data, pre- and post-1970. TZ database would not be what it is without contributions and ongoing effort by the "astrological community". I fully support Thomas Finch's proposal:
I think the way to fix this is to revert both policy changes, and revert all the timezone merges.
On 29.09.21 18:53, Paul Eggert via tz wrote:
On 9/29/21 4:20 AM, Tony Finch via tz wrote:
The aim of merging timezones was to avoid political issues and to reduce the maintenance burden. It seems to me that it has failed to achieve those goals.
That being said, pre-1970 timestamps are an area where the long-term maintenance burden is very real and the*overall end-user benefit is exceedingly tiny, even negative. *
Alois Treindl wrote in <60e82e0d-cf77-62b1-0bac-0bf5d5cc86f8@astro.ch>: |On 29.09.21 18:53, Paul Eggert via tz wrote: |> On 9/29/21 4:20 AM, Tony Finch via tz wrote: |>> The aim of merging timezones was to avoid political issues and to reduce |>> the maintenance burden. It seems to me that it has failed to achieve |>> those |>> goals. |> |> That being said, pre-1970 timestamps are an area where the long-term |> maintenance burden is very real and the*overall end-user benefit is |> exceedingly tiny, even negative. * |I absolutely disagree with the claim that end-user benefit of pre-1970 |data is exceedingly tiny. | |*pre-1970 time data are extremely important for hundreds of authors and |millions of users of astrological software.* | |Whatever one may think of astrology, it is a fact that at was |astrologers like Thomas Shanks and others who collected extensive |historical time zone data, pre- and post-1970. | |TZ database would not be what it is without contributions and ongoing |effort by the "astrological community". | |I fully support Thomas Finch's proposal: | |> I think the way to fix this is to revert both policy changes, and revert |> all the timezone merges. I also think data should be reunited. (It would surely be doable to use tooling to automatically unite all zones which are identical post-1970, maybe give that an auto-generated name, and make all actual TZIDs which point to that data links automatically.) What really bugs me with the current post-1970-matters rule is that the "ZFLAGS='-r @0'" option is neither default nor prominently documented. In conjunction with the zone moving pre-1970 dates may point to wrong zones, instead "of only being wrong" (which they may well be anyway). Also that tzselect(8) gives the name of the actually really used zone instead of the name that was used is ugly, as could be seen by asking for Europe/Copenhagen and getting "using Europe/Berlin". As TZIDs are stable it should not matter what the actual name of the dataset is, only the TZID is of interest. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
On 10/4/21 12:59 PM, Steffen Nurpmeso via tz wrote:
(It would surely be doable to use tooling to automatically unite all zones which are identical post-1970, maybe give that an auto-generated name, and make all actual TZIDs which point to that data links automatically.)
I wrote such a tool to generate the May proposal, except that I didn't invent new names as I thought that would entail unnecessary complexity and confusion. It was kind of a hack, though, and not worth publishing.
What really bugs me with the current post-1970-matters rule is that the "ZFLAGS='-r @0'" option is neither default nor prominently documented.
Making it the default would be a big lift, as people have expressed concern about churn in pre-1970 data. In hindsight perhaps we should have omitted pre-1970 data from the start (it sure would have saved me a lot of ill-spent time ...) but the backward-compatibility concerns do exist even if they're perhaps overblown.
Also that tzselect(8) gives the name of the actually really used zone instead of the name that was used
Could you explain more about this issue? I don't see how a "name that was used" is involved here. When a user starts up tzselect, there is no name yet. tzselect is supposed to let you choose a name de novo. Perhaps you could show a sample tzselect session and explain where it goes wrong? As for the importance of astrological use of the tzdb main entries - tzdb has never been remotely adequate for pre-1970 timestamps, and I see no movement on the horizon to fix this. I have asked an astrologer or two for help on this topic with no results, not that I expected any; any effort in this area would have to be huge to get decent coverage. Here's one way to think about it. After about 40 years of volunteer work, we have reasonable coverage for casting horoscopes for people aged 50 or less. On current trends we can solve the problem of casting horoscopes for living persons, simply by doing nothing for the next 40 years or so. Perhaps that's not ideal for astrologers, but it's pretty good bang for the buck.
Hello. Paul Eggert wrote in <d23f4a05-b5c4-d592-900c-b7ea5bbbfea0@cs.ucla.edu>: |On 10/4/21 12:59 PM, Steffen Nurpmeso via tz wrote: |> (It would surely be doable to use tooling to automatically unite |> all zones which are identical post-1970, maybe give that an |> auto-generated name, and make all actual TZIDs which point to that |> data links automatically.) | |I wrote such a tool to generate the May proposal, except that I didn't |invent new names as I thought that would entail unnecessary complexity |and confusion. It was kind of a hack, though, and not worth publishing. It would also introduce nothing but harm on operating systems / filesystems which do not support links. (Unless everything would be organized totally different, which surely is a no-go for IANA TZ.) Yes. |> What really bugs me with the current post-1970-matters rule is |> that the "ZFLAGS='-r @0'" option is neither default nor |> prominently documented. | |Making it the default would be a big lift, as people have expressed |concern about churn in pre-1970 data. In hindsight perhaps we should |have omitted pre-1970 data from the start (it sure would have saved me a |lot of ill-spent time ...) but the backward-compatibility concerns do |exist even if they're perhaps overblown. I am still thrilled by the collected knowledge, and i am happy that the thread has settled. But i personally see no difference in between the value of Europe/Copenhagen on the one hand, and Asia/Vientiane or /Phnom_Penh on the other. Your argument seems a bit fishy though given the post-1970 direction of the last years. And yes, it is possible to use a negative time_t regulary on the systems i have tried. Death has taken a toll on those people who can be truly fooled when they use date(1) to look up the date of their birth, though. |> Also that tzselect(8) gives the name of the actually really used |> zone instead of the name that was used | |Could you explain more about this issue? I don't see how a "name that |was used" is involved here. When a user starts up tzselect, there is no |name yet. tzselect is supposed to let you choose a name de novo. | |Perhaps you could show a sample tzselect session and explain where it |goes wrong? Of course. Now that Europe/Copenhagen has been reverted i take the example from above. #?0|kent:tz.git$ tzselect ... 4) Asia [...] #? 4 Please select a country whose clocks agree with yours. ... 2) Antarctica 9) Cambodia [...] #? 9 The following information has been given: Cambodia Indochina (most areas) Therefore TZ='Asia/Bangkok' will be used. ... Is the above information OK? 1) Yes 2) No #? 1 You can make this change permanent for yourself by appending the line TZ='Asia/Bangkok'; export TZ to the file '.profile' in your home directory; then log out and log in again. Here is that TZ value again, this time on standard output so that you can use the /usr/bin/tzselect command in shell scripts: Asia/Bangkok The announced nature of TZIDs are so the name of a dataset is ok, but since "Link"s are stable and do work as such #?0|kent:tz.git$ TZ=Asia/Bangkok date Wed Oct 6 04:07:51 +07 2021 #?0|kent:tz.git$ TZ=Asia/Phnom_Penh date Wed Oct 6 04:07:53 +07 2021 i would simply output the name of the link, maybe like so The following information has been given: ... Therefore TZ='Asia/Phnomh_Penh' will be used. It is a link pointing to the dataset TZ='Asia/Bangkok'. Do not treat this too seriously. The problem is that tzselect(8) uses nifty information linking of and in between zone1970.tab and iso3166.tab, and in particular zone1970.tab. The problem with the land of the thousand elephants etc. was among the first changes in 2014-07. It could only be changed (without additional data files / code changes) by adjusting zone1970.tab to no longer join multiple country-codes per line. The datasets could still be shared, but of course it is a maintenance burden as the comment field must be identical. Or some kind of "link" had to be understood also in zone1970.tab, so that the name is retained, but the dataset can be targeted nonetheless. This could require multi-pass, then. .... But, ach. Forget it, i really would not do it like you do :) It is really neat and .. it is really, really neat. :) (I was just wondering shortly about not using (^|,)X(,|$) for the country-code regular expression, but it seems to work for all of ISO 3166, so why bother? I think.) But i would use zone.tab as it was back in 2014. From this short glance i cannot see how it would hurt the unsharing process. It is just, you know, renaming the master branch to main explicitly is hard to get in line with beating Buddhists like that, just in case they would feel equally hurt like our Danish dynamite friend did. Of course the intention is understood. They also do not seem to bother the slicing. I think maintaining the TZ DB is not an easy task. |As for the importance of astrological use of the tzdb main entries - |tzdb has never been remotely adequate for pre-1970 timestamps, and I see |no movement on the horizon to fix this. I have asked an astrologer or |two for help on this topic with no results, not that I expected any; any |effort in this area would have to be huge to get decent coverage. | |Here's one way to think about it. After about 40 years of volunteer |work, we have reasonable coverage for casting horoscopes for people aged |50 or less. On current trends we can solve the problem of casting |horoscopes for living persons, simply by doing nothing for the next 40 |years or so. Perhaps that's not ideal for astrologers, but it's pretty |good bang for the buck. (This was for Alois Treindl. You had written his surename wrong in a comment in the patch you posted last / a few hours ago.) --End of <d23f4a05-b5c4-d592-900c-b7ea5bbbfea0@cs.ucla.edu> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
On 10/5/21 15:38, Steffen Nurpmeso wrote:
It would also introduce nothing but harm on operating systems / filesystems which do not support links.
That shouldn't be a problem, as zic does not rely on operating-system links to support its 'Link' command. zic uses hard links if available, otherwise symbolic links if available, otherwise copies.
i would simply output the name of the link, maybe like so
The following information has been given: ... Therefore TZ='Asia/Phnomh_Penh' will be used. It is a link pointing to the dataset TZ='Asia/Bangkok'.
OK, I see. You can get the effect you want in tzdb 2021c, by using the command 'tzselect -t zone'. However, the -t option is not documented as it wasn't clear to me how this should work in general. Perhaps it should be documented and/or generalized.
(This was for Alois Treindl. You had written his surename wrong in a comment in the patch you posted last / a few hours ago.)
Thanks for mentioning this. I see I've made this mistake on multiple occasions. My apologies. Proposed patch attached, and installed into the development repository.
Paul Eggert wrote in <a590de23-4aea-6286-6657-0741ed81dc18@cs.ucla.edu>: |On 10/5/21 15:38, Steffen Nurpmeso wrote: ... |> i would simply output the name of the link, maybe like so |> |> The following information has been given: |> ... |> Therefore TZ='Asia/Phnomh_Penh' will be used. |> It is a link pointing to the dataset TZ='Asia/Bangkok'. | |OK, I see. You can get the effect you want in tzdb 2021c, by using the |command 'tzselect -t zone'. However, the -t option is not documented as |it wasn't clear to me how this should work in general. Perhaps it should |be documented and/or generalized. ... Oh yes, thank you. Works. (Using zone.tab by default seems more useful to me, as tzselect is meant for end-users.) ..I did not write a documentation patch now.. Ciao, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
participants (7)
-
Alois Treindl -
Eliot Lear -
Paul Eggert -
Philip Paeps -
Scott Kilpatrick -
Steffen Nurpmeso -
Tony Finch