Moving more zones to 'backzone'
Release 2021b moved to 'backzone' nine zones whose timestamps since 1970 were duplicates of other zones, as part of a process that started in 2013 in the interests of removing prior inequities, one step at a time. If we were to continue this process in the same way, we could install the attached proposed patch which would move more zones, chosen via the same procedure used for 2021b. It strikes me, though, now that Stephen Colebourne has established a mechanism that can let downstream users keep the duplicate-since-1970 zones, that it may be a more effective use of our time to move the rest of the duplicate-si ce-1970 zones now, while no urgent changes are pending. This would move another twelve zones if I've counted correctly, and would let us more efficiently turn our attention to other issues. Comments welcome.
My immediate reaction is that this issue caused a fork, and your response now appears to be: Good, let’s widen the difference between the forks. I do not believe two forks of this database is a good idea, and I do not believe the benefit of equity outweighs the disadvantages of the existence of a fork. Howard On Jul 7, 2022, at 9:44 AM, Paul Eggert via tz <tz@iana.org> wrote:
Release 2021b moved to 'backzone' nine zones whose timestamps since 1970 were duplicates of other zones, as part of a process that started in 2013 in the interests of removing prior inequities, one step at a time. If we were to continue this process in the same way, we could install the attached proposed patch which would move more zones, chosen via the same procedure used for 2021b.
It strikes me, though, now that Stephen Colebourne has established a mechanism that can let downstream users keep the duplicate-since-1970 zones, that it may be a more effective use of our time to move the rest of the duplicate-si ce-1970 zones now, while no urgent changes are pending. This would move another twelve zones if I've counted correctly, and would let us more efficiently turn our attention to other issues.
Comments welcome. <0001-Move-9-more-zones-to-backzone.patch>
On 2022-07-07 21:59:39 (+0800), Howard Hinnant via tz wrote:
On Jul 7, 2022, at 9:44 AM, Paul Eggert via tz <tz@iana.org> wrote:
Release 2021b moved to 'backzone' nine zones whose timestamps since 1970 were duplicates of other zones, as part of a process that started in 2013 in the interests of removing prior inequities, one step at a time. If we were to continue this process in the same way, we could install the attached proposed patch which would move more zones, chosen via the same procedure used for 2021b.
It strikes me, though, now that Stephen Colebourne has established a mechanism that can let downstream users keep the duplicate-since-1970 zones, that it may be a more effective use of our time to move the rest of the duplicate-si ce-1970 zones now, while no urgent changes are pending. This would move another twelve zones if I've counted correctly, and would let us more efficiently turn our attention to other issues.
Comments welcome. <0001-Move-9-more-zones-to-backzone.patch>
My immediate reaction is that this issue caused a fork, and your response now appears to be: Good, let’s widen the difference between the forks.
That was my immediate reaction too. My second reaction was: but is anyone using the fork? Followed by, very shortly after: and will these proposed changes push more people to the fork?
I do not believe two forks of this database is a good idea, and I do not believe the benefit of equity outweighs the disadvantages of the existence of a fork.
I agree wholeheartedly! Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
At this point, I think it is established that I disagree with the basis behind removing data from tzdb for the entirely incorrect and spurious reason of "equality" (given that it actually makes tzdb less equal, not more). It is also well established that Paul as tzdb co-ordinator has complete power here to take whatever action he chooses, and the list has shown itself unwilling to challenge that. I setup global-tz as an automated fork of tzdb with two main purposes: 1) To provide a convenient and reliable way to access the data as though changes since 2013 had never happened. 2) To demonstrate what tzdb itself could do to resolve the disagreement. https://github.com/JodaOrg/global-tz To elaborate on point 2, it would be perfectly possible to change tzdb as follows: - create a new "dev" branch where the raw tzdb data lives and is edited - create a script (GitHub Action) that runs on every commit to process the dev branch - the script would process dev branch and create the contents of the current main branch - and the script would process dev branch and create the contents of global-tz on a "global" branch - a further branch could be created where the data is processed to remove all pre-1970 data This would allow global-tz to close, as the same data would then be available in tzdb (on the global branch). Effectively this would allow tzdb to take ownership of the fork, but the fork would still exist. I would also encourage downstream consumers to think long and hard about what they will do should this proposal proceed. Is your project willing to defend Paul's rationale? Is your project willing to accept that the German time-zone is considered more important than the Swedish or Norwegian one? The Netherlands more important than Belgium? Or the Ivory Coast more important than Iceland? If not, then you are going to need to switch to global-tz (or find some other solution). It would be good to see a statement from some larger companies on this matter (eg. Apple, Oracle, Android/Google etc, RedHat). For the record, I have no interest or desire to maintain a fork - it is simply something forced by what I consider to be unacceptable changes to tzdb.. thanks Stephen On Thu, 7 Jul 2022 at 14:45, Paul Eggert via tz <tz@iana.org> wrote:
Release 2021b moved to 'backzone' nine zones whose timestamps since 1970 were duplicates of other zones, as part of a process that started in 2013 in the interests of removing prior inequities, one step at a time. If we were to continue this process in the same way, we could install the attached proposed patch which would move more zones, chosen via the same procedure used for 2021b.
It strikes me, though, now that Stephen Colebourne has established a mechanism that can let downstream users keep the duplicate-since-1970 zones, that it may be a more effective use of our time to move the rest of the duplicate-si ce-1970 zones now, while no urgent changes are pending. This would move another twelve zones if I've counted correctly, and would let us more efficiently turn our attention to other issues.
Comments welcome.
On 8 July 2022 14:31:16 CEST, Stephen Colebourne via tz <tz@iana.org> wrote:
I would also encourage downstream consumers to think long and hard about what they will do should this proposal proceed. Is your project willing to defend Paul's rationale? Is your project willing to accept that the German time-zone is considered more important than the Swedish or Norwegian one?
I can't justify this to my users, so will have to spend time and effort to move to your fork. Which I consider a waste of time to be forced to have to do. cheers Derick
The proposed time zone merges won't affect many Android users, so Android is likely to continue to use official TZDB releases (as ICU), albeit the rearguard data set (as ICU). Android users primarily need correct local time offsets for the recent past, the current moment and a few years into the future. Android stopped to use backzone data in Pie (released in 2018) and the latest time zone update includes recent time zone merges. There were no user reported bugs related to pre-1970 time zone data quality so far. On Android we keep metadata which associates zone IDs with ISO country codes which is used in time zone picker. Paul's recent time zone merges caused problems and we had to patch tzdata. I concluded the changes are permanent and had time to update our tooling. Currently Android relies on TZDB for time zone rules / TZif generation excluding the backward file and tzcode for Android's libc. As long as old IDs are kept, such merges do not affect Android. On Fri, 8 Jul 2022 at 13:31, Stephen Colebourne via tz <tz@iana.org> wrote:
At this point, I think it is established that I disagree with the basis behind removing data from tzdb for the entirely incorrect and spurious reason of "equality" (given that it actually makes tzdb less equal, not more). It is also well established that Paul as tzdb co-ordinator has complete power here to take whatever action he chooses, and the list has shown itself unwilling to challenge that.
I setup global-tz as an automated fork of tzdb with two main purposes:
1) To provide a convenient and reliable way to access the data as though changes since 2013 had never happened. 2) To demonstrate what tzdb itself could do to resolve the disagreement.
https://github.com/JodaOrg/global-tz
To elaborate on point 2, it would be perfectly possible to change tzdb as follows: - create a new "dev" branch where the raw tzdb data lives and is edited - create a script (GitHub Action) that runs on every commit to process the dev branch - the script would process dev branch and create the contents of the current main branch - and the script would process dev branch and create the contents of global-tz on a "global" branch - a further branch could be created where the data is processed to remove all pre-1970 data This would allow global-tz to close, as the same data would then be available in tzdb (on the global branch). Effectively this would allow tzdb to take ownership of the fork, but the fork would still exist.
I would also encourage downstream consumers to think long and hard about what they will do should this proposal proceed. Is your project willing to defend Paul's rationale? Is your project willing to accept that the German time-zone is considered more important than the Swedish or Norwegian one? The Netherlands more important than Belgium? Or the Ivory Coast more important than Iceland? If not, then you are going to need to switch to global-tz (or find some other solution). It would be good to see a statement from some larger companies on this matter (eg. Apple, Oracle, Android/Google etc, RedHat).
For the record, I have no interest or desire to maintain a fork - it is simply something forced by what I consider to be unacceptable changes to tzdb..
thanks
Stephen
On Thu, 7 Jul 2022 at 14:45, Paul Eggert via tz <tz@iana.org> wrote:
Release 2021b moved to 'backzone' nine zones whose timestamps since 1970 were duplicates of other zones, as part of a process that started in 2013 in the interests of removing prior inequities, one step at a time. If we were to continue this process in the same way, we could install the attached proposed patch which would move more zones, chosen via the same procedure used for 2021b.
It strikes me, though, now that Stephen Colebourne has established a mechanism that can let downstream users keep the duplicate-since-1970 zones, that it may be a more effective use of our time to move the rest of the duplicate-si ce-1970 zones now, while no urgent changes are pending. This would move another twelve zones if I've counted correctly, and would let us more efficiently turn our attention to other issues.
Comments welcome.
NetBSD will continue using Stephen Colebourne's fork - the last "official" release we used was 2021a - before that I simply made the changes that matter to what was 2021a to compensate for changes to zones that correctly affected timestamps, and ignored all the rubbish that was discarding pre-1970 data. Stephen's script and distribution of the results makes that simpler. We will continue using that as long as it is available, and needed, and if the former ceases while the need remains, we'll go back to managing ourselves. While some of the pre 1970 data might not be as accurate as we'd like, most of it is more accurate than having no data at all for the zone, or worse, pretending some other zone's data applies. If the intent was to truly stop caring about anything pre 1970, then you'd remove all of the pre 1970 data from all zones, and make localtime() error out when given a time that produces tm_year < 1970. That would at least be correct (in some sense), if not very useful. If the real reason for this is the workload of dealing with more zones, then simply acquire more helpers - they don't need to be delegated authority to make changes at will, but could easily help with editing changes that you want to make, and making sure that all the zones that should be updated, get updated - it doesn't need to be entirely a 2 man show (and not only would that reduce your workload, it would help train future potential co-ordinators). An enhanced zic (or wholly redesigned) input format, or a pre-processor (though ideally not that) to assist would be a good idea - and if you have someone (or several) helping with the routine (more than just Tim) then maybe you'd have the time to make that happen - that must be more interesting than just editing zone files. The first thing any such helpers should do is to restore all the zones that have been (effectively) removed (shunted into backzone) and make sure that any updates that should have been applied to them are applied. On the other hand, if this is all the "equity" nonsense, then the merges should simply be reversed - all the way back to when they started. I have seen here no arguments at all that justify any merges, not even close. If there are "hidden pressures" those really should be ignored unless those applying that pressure make a case here, in public, for their concerns, that we can agree or disagree with. If you're unable, for whatever reason, to resist something like that - to do nothing unless the change is agreed here, then you really should resign, and allow someone else to take over. kre
I view maintaining the pre-1970 data as an exercise in improving the historical record of timezone information. Historians don't simply discard information when they are not certain about its accuracy. They constantly work to make it better. In extreme cases it is called https://en.wikipedia.org/wiki/Historical_revisionism <https://en.wikipedia.org/wiki/Historical_revisionism>. I don't see any other group of people trying to do this work, so like it or not we are the best positioned group to maintain this information right now. I believe that we should provide the best information to our knowledge instead of giving up and discarding it because of convenience. I also agree with kre that the arcane zic format needs to be redesigned to ease maintenance. Best, christos
On 7/8/22 13:14, Robert Elz wrote:
If the real reason for this is the workload of dealing with more zones, then simply acquire more helpers
Would you like to be a helper? I'd be happy to delegate the job of maintaining 'backzone' data. Also, I'm open to improving 'zic' to make maintenance easier. For example, several people have proposed making it easy for Zone X to say "I'm like Zone Y from 1920 through 1965", and if done right that would be a real win - though writing the code for this would likely not be trivial, and we could use it only in vanguard form for a while. In short, patches are welcome (please use git format-patch form). Getting back to your comment, technical workload is not the main reason to move data to 'backzone'. Politics are more important. For political reasons many people care about data that are practically insignificant, and these political concerns are a major long-term hazard to this project. We're better off heading off these potential disputes at the pass, by maintaining the database via nonpolitical guidelines and being consistent about that, even if nobody has yet complained politically about a particular data item. Of course we cannot forestall all possible political complaints; still, it's a win to be as nonpolitical as we reasonably can. From my point of view, the disagreement that caused the fork was a tempest in a rather small teapot, as it has almost no practical consequences for TZDB. Users by and large simply don't care about minor discrepancies in pre-1970 timestamps. And the few users who do care (mostly astrologers) are so ill-served by the completely inadequate data in 'backzone' that its presence or absence doesn't matter all that much to them either. Although nobody is happy about the fork, the difference between the two variants is so small that it's not worth worrying about from the vast majority of users. TZDB already has options that have way bigger consequences, such as the options to remove all pre-1970 data, or to add leap seconds, or to incorporate even more data from 'backzone'; so it should be OK for TZDB to have this new option too. For this reason, I wrote, circulated[1] and today installed patches to let TZDB optionally emulate global-tz exactly, in the sense that the two approaches generate identical TZif files; and the recently-installed tailored_tarballs target[2] should suffice for Java-like downstream users. In reading through the comments on this thread, nobody expressed an opinion on the idea of finishing the move to 'backzone' now instead of doing it in dribs and drabs. So I finished the move now by installing the attached patches into the development version on GitHub as there seemed to be no benefit to delaying this further, given the recently added installation options. The first of these two patches was circulated about a month ago[3]; the second finishes the job of moving to 'backzone' the location-based zones that are redundant since 1970. In the default build, these two patches affect only pre-1970 timestamps. With the new 'make PACKRATDATA=backzone PACKRATLIST=zone.tab' option, these two patches don't affect any timestamps and the result generates TZif files identical to those generated by global-tz. [1] https://mm.icann.org/pipermail/tz/2022-July/031717.html [2] https://mm.icann.org/pipermail/tz/2022-July/031710.html [3] https://mm.icann.org/pipermail/tz/2022-July/031631.html
Fast or slow didn’t really seem to be the issue for everyone who responded to this thread. I’m not sure what the purpose is of presenting the patches, if you’re not going to heed the feedback anyway. Imho, this database is way too important to have a single decision maker and IANA is grossly mishandling it by managing it that way. Committees are far from perfect. They make mistakes too. But they are a better solution than what is going on here. Sorry to be so blunt. But I felt like this needed saying. Howard On Aug 3, 2022, at 3:57 PM, Paul Eggert via tz <tz@iana.org> wrote:
In reading through the comments on this thread, nobody expressed an opinion on the idea of finishing the move to 'backzone' now instead of doing it in dribs and drabs. So I finished the move now by installing the attached patches into the development version on GitHub as there seemed to be no benefit to delaying this further, given the recently added installation options.
Quoting Howard Hinnant via tz on Wednesday August 03, 2022:
Imho, this database is way too important to have a single decision maker and IANA is grossly mishandling it by managing it that way. Committees are far from perfect. They make mistakes too. But they are a better solution than what is going on here. Sorry to be so blunt. But I felt like this needed saying.
Perhaps a clarification is in order here. RFC 6557 (BCP 175) is the governing document that defines roles and responsibilities for this project and, in short, your email suggests IANA is delinquent in performing in a role it does not have. "Updates to the TZ database are made by the TZ Coordinator in consultation with the TZ mailing list. The TZ Coordinator is empowered to decide, as the designated expert, appropriate changes, but SHOULD take into account views expressed on the mailing list." Our defined role is essentially to host this project and to ensure the infrastructure is in place such that it endures beyond any individual contributor or TZ Coordinator. The TZ Coordinators are designated by the Internet Engineering Steering Group, which also manages the appeals process described in the document. kim
On Aug 3, 2022, at 8:38 PM, Kim Davies via tz <tz@iana.org> wrote:
Quoting Howard Hinnant via tz on Wednesday August 03, 2022:
Imho, this database is way too important to have a single decision maker and IANA is grossly mishandling it by managing it that way. Committees are far from perfect. They make mistakes too. But they are a better solution than what is going on here. Sorry to be so blunt. But I felt like this needed saying.
Perhaps a clarification is in order here. RFC 6557 (BCP 175) is the governing document that defines roles and responsibilities for this project and, in short, your email suggests IANA is delinquent in performing in a role it does not have. "Updates to the TZ database are made by the TZ Coordinator in consultation with the TZ mailing list. The TZ Coordinator is empowered to decide, as the designated expert, appropriate changes, but SHOULD take into account views expressed on the mailing list."
Our defined role is essentially to host this project and to ensure the infrastructure is in place such that it endures beyond any individual contributor or TZ Coordinator. The TZ Coordinators are designated by the Internet Engineering Steering Group, which also manages the appeals process described in the document.
kim
Thank you for the clarification. I stand corrected. Howard
On Wed, 3 Aug 2022 at 20:58, Paul Eggert via tz <tz@iana.org> wrote:
Getting back to your comment, technical workload is not the main reason to move data to 'backzone'. Politics are more important. For political reasons many people care about data that are practically insignificant, and these political concerns are a major long-term hazard to this project. We're better off heading off these potential disputes at the pass, by maintaining the database via nonpolitical guidelines and being consistent about that, even if nobody has yet complained politically about a particular data item. Of course we cannot forestall all possible political complaints; still, it's a win to be as nonpolitical as we reasonably can.
From my point of view, the disagreement that caused the fork was a tempest in a rather small teapot
It is sad that after many emails exchanged on the topic there is still no understanding of why these changes are so offensive. It ought to be obvious that wiping out the time-zone history of Oslo or Stockholm in favour of Berlin is a political and cultural statement that the project simply should not be making. As I've said before, I view these time-zone merges as a form of (US) imperialism against smaller countries that only have one time-zone. In no way shape or form are the merges "nonpolitical". As a reminder, it never has been much about pre-1970 data for me - removing all pre-1970 data from the main distribution would have been a logical choice for example.
In reading through the comments on this thread, nobody expressed an opinion on the idea of finishing the move to 'backzone' now instead of doing it in dribs and drabs. So I finished the move now by installing the attached patches into the development version on GitHub as there seemed to be no benefit to delaying this further, given the recently added installation options.
Indeed. If the new option can be made to perform acceptably (see other thread) then it is not unreasonable to perform the additional merges. ie. I and others disagree with the merges, but there is no mechanism to stop your decision. What this does is push the problem to downstream projects. My hope is that downstream users will understand and appreciate that: - Iceland's time zone now points at Africa/Abidjan - Sweden's time zone data now points at Europe/Berlin - Norway's time zone data now points at Europe/Berlin - Netherland's time-zone data now points at Europe/Brussels and many more. Each downstream project is now on the hook for the political sensitivity of this choice. (I'd like to hear from Robert Elz as to whether he views the generated tarballs as sufficient for NetBSD) Stephen
* Stephen Colebourne via tz:
It is sad that after many emails exchanged on the topic there is still no understanding of why these changes are so offensive. It ought to be obvious that wiping out the time-zone history of Oslo or Stockholm in favour of Berlin is a political and cultural statement that the project simply should not be making. As I've said before, I view these time-zone merges as a form of (US) imperialism against smaller countries that only have one time-zone. In no way shape or form are the merges "nonpolitical".
I'm not sure if the above is an appropriate characterization, but I want to point out that switching much of Europe to Europe/Berlin will leaves us ill-equipped to deal with future time zone fragmentation after mandatory DST has been abolished in Europe, and different countries make different choices. Thanks, Florian
Florian Weimer via tz wrote:
* Stephen Colebourne via tz:
It is sad that after many emails exchanged on the topic there is still no understanding of why these changes are so offensive. It ought to be obvious that wiping out the time-zone history of Oslo or Stockholm in favour of Berlin is a political and cultural statement that the project simply should not be making. As I've said before, I view these time-zone merges as a form of (US) imperialism against smaller countries that only have one time-zone. In no way shape or form are the merges "nonpolitical".
I'm not sure if the above is an appropriate characterization, but I want to point out that switching much of Europe to Europe/Berlin will leaves us ill-equipped to deal with future time zone fragmentation after mandatory DST has been abolished in Europe, and different countries make different choices.
Once more, I fully agree. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com
On 04.08.22 09:24, Florian Weimer via tz wrote:
I'm not sure if the above is an appropriate characterization, but I want to point out that switching much of Europe to Europe/Berlin will leaves us ill-equipped to deal with future time zone fragmentation after mandatory DST has been abolished in Europe, and different countries make different choices.
Let's be specific. I think the example in question is if Berlin and Stockholm diverge due to one wanting DST and the other not. At that point, what happens to Stockholm? Does it get a new or does it point to another city? Eliot
Eliot Lear via tz said:
I'm not sure if the above is an appropriate characterization, but I want to point out that switching much of Europe to Europe/Berlin will leaves us ill-equipped to deal with future time zone fragmentation after mandatory DST has been abolished in Europe, and different countries make different choices.
Let's be specific. I think the example in question is if Berlin and Stockholm diverge due to one wanting DST and the other not. At that point, what happens to Stockholm? Does it get a new or does it point to another city?
The area covered by Europe/Berlin will split into two time zones (in the TZ sense). We identify the largest city in each (one of which will presumably be Berlin) and ensure we have zones for each, either by creating new ones or reinstating ones that have been moved to backzone. If Sweden is the only country to take the opposite view to Germany, then the zones will be Europe/Berlin and Europe/Stockholm. At which point I'd expect us to re-instate all the data that got lost when the merge happened. If other countries disagree with Germany, Stockholm might not be the largest city (I can't be bothered to look up what the merges were) but the principle still applies. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
Florian Weimer via tz said:
I'm not sure if the above is an appropriate characterization, but I want to point out that switching much of Europe to Europe/Berlin will leaves us ill-equipped to deal with future time zone fragmentation after mandatory DST has been abolished in Europe, and different countries make different choices.
I disagree. In fact, I think it's scaremongering. Ignoring Ireland, which is already a special case, and overseas territories, which aren't affected anyway, there's only three current timezones in the EU (in terms of current rules, ignoring all history ever). If, for example Sweden decides to stay on winter time and the rest of the EU decide to stay on +2, then we split Europe/Stockholm back off Europe/Berlin *and do nothing else*. This is exactly the same as if we suddenly discovered that Sweden had changed time a week later than everyone else in 1984. And is no more work than if we'd discovered that Berwick-on-Tweed hadn't observed BST in 1976. As far as I can see, the *most* that the EU change will do is require us to split each of these merged zones into two and to newly split Europe/Belgrade and Europe/Prague. And that's only if countries make the worst-possible choices and the Commission doesn't override them. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
* Clive D. W. Feather:
Florian Weimer via tz said:
I'm not sure if the above is an appropriate characterization, but I want to point out that switching much of Europe to Europe/Berlin will leaves us ill-equipped to deal with future time zone fragmentation after mandatory DST has been abolished in Europe, and different countries make different choices.
I disagree. In fact, I think it's scaremongering.
Ignoring Ireland, which is already a special case, and overseas territories, which aren't affected anyway, there's only three current timezones in the EU (in terms of current rules, ignoring all history ever). If, for example Sweden decides to stay on winter time and the rest of the EU decide to stay on +2, then we split Europe/Stockholm back off Europe/Berlin *and do nothing else*. This is exactly the same as if we suddenly discovered that Sweden had changed time a week later than everyone else in 1984. And is no more work than if we'd discovered that Berwick-on-Tweed hadn't observed BST in 1976.
The benefit of the current scheme is that users can keep using Europe/Stockholm (or the local equivalent for most European countries) before and after the migration off DST. This means they will be able to implement the migration without a configuration change, just with a software update. If we tell them to switch to Europe/Berlin first, and then to some other city outside their country, that creates unnecessary work and friction. Thanks, Florian
On 8/4/22 03:02, Florian Weimer via tz wrote:
If we tell them to switch to Europe/Berlin first
Let's not do that. People who use Europe/Stockholm can continue to use the name, just as people who use America/Fort_Wayne and Asia/Chongqing can still use those names even though their Zones were removed years ago. We can treat Stockholm the same way we successfully treated Fort Wayne and Chongqing.
Stephen Colebourne via tz wrote: [...]
It is sad that after many emails exchanged on the topic there is still no understanding of why these changes are so offensive. It ought to be obvious that wiping out the time-zone history of Oslo or Stockholm in favour of Berlin is a political and cultural statement that the project simply should not be making. As I've said before, I view these time-zone merges as a form of (US) imperialism against smaller countries that only have one time-zone. In no way shape or form are the merges "nonpolitical".
I fully agree. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com
Stephen Colebourne via tz:
What this does is push the problem to downstream projects. My hope is that downstream users will understand and appreciate that:
- Iceland's time zone now points at Africa/Abidjan - Sweden's time zone data now points at Europe/Berlin - Norway's time zone data now points at Europe/Berlin - Netherland's time-zone data now points at Europe/Brussels and many more.
The removal of the data isn't so much of a problem as trying to explain to users what they get. In the system I am writing, I am using zone1970.tab as the source for time zones, using the time zone name (sans continent) and the description. I sort time zones on current time, so it is fairly easy to find the zones that correspond to the current location as long as the system time is correct. The problem is trying to understand which time zone to pick when none of the cities in your country are listed. Windows already has this problem with its time zone picker, it has a couple of time zones that cover CET, none that list any cities or contries that are relevant to me, so I just have to pick one at random. Moving the TZDB in that direction is not the best solution. I have been considering switching to global-tz for the next update, but I just realize that it has the same zone1970.tab file as regular tz, so that will not help at all (I am writing for an embedded system where we cut off old data from before build time, as it does not preserve information across reboots in anything but fully written-out text form). -- \\// Peter - http://www.softwolves.pp.se/
On Aug 4, 2022, at 5:12 AM, Peter Krefting via tz <tz@iana.org> wrote:
The problem is trying to understand which time zone to pick when none of the cities in your country are listed.
This is a problem with the tzdb only when the list of tzids is used as the source of the list of cities. macOS, iOS, and iPadOS do *not* use the list of tzids as the source of the list of cities, and I think may also be the case for Android. It's also the case for Ubuntu does during system setup but, unfortunately, not after the system is set up.
On 8/4/22 05:12, Peter Krefting via tz wrote:
I have been considering switching to global-tz for the next update, but I just realize that it has the same zone1970.tab file as regular tz, so that will not help at all
Yes, that's right. The only difference between global-tz and default TZDB is that the former has some Zones that differ only in pre-1970 timestamps. Global-tz won't help if your app involves post-1970 timestamps (which is what embedded systems invariably do). The same is true for TZDB's new PACKRATLIST option, as it is equivalent to global-tz.
(I am writing for an embedded system where we cut off old data from before build time, as it does not preserve information across reboots in anything but fully written-out text form).
In that case, even zone1970.tab is overkill for your application, which doesn't care about zones that differ only for timestamps in the past. On my long list of things to do, is to create a file zonenow.tab that would cater to systems that need only timestamps now and in the future. This table would have fewer entries than zone1970.tab and should be significantly easier to use - it will make it easier to "explain to users what they get", as you put it, as it's hard to explain regions that differ only due to past timestamps. Although zonenow.tab should be useful it won't suffice in the long run. If we assume the sort of timekeeping changes that we've seen in the last century or so, in the long run the current maintenance approach will likely grow the number of Zones exponentially until it approaches the number of locations on the planet. I don't think anybody would want to maintain that many Zones. We will need a better approach, one that will surely require changes to the format of zic's input and output.
Paul Eggert via tz:
just realize that it has the same zone1970.tab file as regular tz, so that will not help at all
Yes, that's right. The only difference between global-tz and default TZDB is that the former has some Zones that differ only in pre-1970 timestamps.
Indeed. It solves the problem I do not have, without solving the problem I do have.
(I am writing for an embedded system where we cut off old data from before build time, as it does not preserve information across reboots in anything but fully written-out text form).
In that case, even zone1970.tab is overkill for your application, which doesn't care about zones that differ only for timestamps in the past.
The zone1970.tab files provides me with a list of time zones, one per country, which can be presented to the person to select the time zone. Having one unique current time zone per country (and more for the few countries that have more than one current time zone) makes it easy to find a zone to select With the zone1970.tab change in 2022b, it is not immediately obvious that for Norway, I should select "Berlin" (although I have added the commentary, so it does say "Scandinavia"). Our customers in Iceland will probably have a harder time as there is no commentary in zone1970.tab (besides the country code) that says Iceland, plus that it has placed Iceland in Africa (which is a bit weird). Of course, they could just select "UTC" and be done with it, which is probably what they do, anyway. For my purposes, I am fine with adding backzone zones to the list, but I will probably revert the changes from 35fa37fbbb152f5d and 0b925f6d8aaf927a from zone1970.tab, and work with that. I will have to experiment with changing the code to parse the zone1970.tab country list, and break it up by that, showing only the country name and the comment in the selector. -- \\// Peter - http://www.softwolves.pp.se/
On 8/11/22 05:39, Peter Krefting wrote:
The zone1970.tab files provides me with a list of time zones, one per country
Not sure about the "one per country" part. Some countries have more than one Zone, and some Zones have more than one country.
With the zone1970.tab change in 2022b, it is not immediately obvious that for Norway, I should select "Berlin" (although I have added the commentary, so it does say "Scandinavia").
Column 1 of the zone1970.tab entry for Europe/Berlin lists NO (Norway) as one of its country code, so if software looks at column 1 it should easily deduce that Europe/Berlin covers at least part of Norway. This sort of issue is not new to 2022b. For example, if software ignores zone1970.tab's column 1 it's not immediately obvious that Europe/Prague covers at least part of Slovakia, and this has been true ever since zone1970.tab was introduced in release 2014f.
I will have to experiment with changing the code to parse the zone1970.tab country list, and break it up by that, showing only the country name and the comment in the selector.
Yes, something like that needs to be done regardless of whether 2022a or 2022b is being used. In looking into this I did notice, though, that tzselect will be confused by 2022b's changes for Iceland, in that 2022b's tzselect doesn't know that Iceland is in the Atlantic, which means if you first select Atlantic, the secondary menu won't mention Iceland. Again, though, this sort of issue is not new to 2022b. For example, in 2022a tzselect if you first choose the Atlantic, tzselect doesn't know that St Helena is in the Atlantic and so its secondary menu won't mention St Helena. Here's another example: if you first choose Asia, 2022a tzselect doesn't know that Turkey is in both Europe and Asia and so its secondary menu doesn't mention Turkey. To work around this longstanding problem I installed the attached proposed patch, which adds comments to zone1970.tab to help tzselect avoid the problems mentioned above, and similarly for Cyprus, Svalbard, Mayotte, etc. I view these comments as experimental; if they work well we can promote them to full-fledged data in some future release and if not then perhaps we can think of something better.
On Fri, 12 Aug 2022, Paul Eggert via tz wrote:
The zone1970.tab files provides me with a list of time zones, one per country Not sure about the "one per country" part. Some countries have more than one Zone, and some Zones have more than one country.
Indeed, a bit poor wording from my side. A vast majority of countries have only one zone, so basing it on country is not such a bad idea. I'm sorry if some of this comes off as a rant, it isn't, it is just me trying to present the data thas is made available to me in a manner that is useful for the end-user of our product, without introducing a lot of extra stuff that I have to maintain myself. My thinking is to display the country names as the top selection entry, as most people know the country they live in, and for the vast majority that is enough (special care has to be taken for the multi-zone countries). I do not do this today. I currently have a simple drop-down selector where I group zones based on the current clock time in the zone (so the list will be ordered differently depending when in the year it is opened), and as the selectable entry I currently have "city" (the BBB part of the AAA/BBB or AAA/CCC/BBB zone specifiers), time zone abbreviation (if any) and the comment. This goes a long way to make it usable, but using the city name isn't the best solution, as many on the list have already noted. Showing "Norway (CEST)" instead of "Oslo (CEST)" would probably be an improvement. Showing "Germany, Denmark, Norway, Sweden, Svalbard (CEST)" probably not as much.
This sort of issue is not new to 2022b. For example, if software ignores zone1970.tab's column 1 it's not immediately obvious that Europe/Prague covers at least part of Slovakia, and this has been true ever since zone1970.tab was introduced in release 2014f.
I was looking for that, but the change predated the zone1970.tab file itself, so I didn't find where to deduplicate that, I need to do some further research on that. We recently released what is likely to be the last patch of the oldest version that have proper time zone support (it supports side-loading timezone updates), so I can only play with the zone1970.tab file to make the list easier to read for those existing systems. -- \\// Peter - http://www.softwolves.pp.se/
On Aug 16, 2022, at 11:28 PM, Peter Krefting via tz <tz@iana.org> wrote:
My thinking is to display the country names as the top selection entry, as most people know the country they live in, and for the vast majority that is enough (special care has to be taken for the multi-zone countries).
Note that the multi-zone countries that are in the top 20 list by population in the Wikipedia list of countries by population, with the exception of China (see below) have about 1.1B people, and several of those in the top 20 list are significant (US, Indonesia, Russia, and Mexico, for example), so that special care definitely should be taken. (Canada and Australia don't make that top-20 list, but they're also multi-zone.) And the comment for Asia/Urumqi says: # Xinjiang Time is well-documented as being officially recognized. E.g., see # "The Working-Calendar for The Xinjiang Uygur Autonomous Region Government" # <http://www.sinkiang.gov.cn/service/ourworking/> (2014-04-22). # Unfortunately, we have no good records of time in Xinjiang before 1986. # During the 20th century parts of Xinjiang were ruled by the Qing dynasty, # the Republic of China, various warlords, the First and Second East Turkestan # Republics, the Soviet Union, the Kuomintang, and the People's Republic of # China, and tracking down all these organizations' timekeeping rules would be # quite a trick. Approximate this lost history by a transition from LMT to # UT +06 at the start of 1928, the year of accession of the warlord Jin Shuren, # which happens to be the date given by Shanks & Pottenger (no doubt as a # guess) as the transition from LMT. Ignore the usage of +08 before # 1986-02-01 under the theory that the transition date to +08 is unknown and # that the sort of users who prefer Asia/Urumqi now typically ignored the # +08 mandate back then. which sounds as if it'd add another 1.4B people, and a very significant world power, to the multi-zone list, even if only a small fraction of those people would use Xinjiang Time.
And then there's more to France than just metropolitan France, so throw another significant power with almost 68M people into the multiple-zone category (that doesn't count the overseas collectivities and New Caledonia), although the vast majority of that population uses Europe/Paris, just as the vast majority of China uses Asia/Shanghai.
Peter Krefting via tz:
I was looking for that, but the change predated the zone1970.tab file itself, so I didn't find where to deduplicate that, I need to do some further research on that.
So I ended up reversing most of the country-merges from 5ddc47fe415a (New file time.tab, superseding zone.tab; 2014-07-18) in our version of the 2022d database release now. I am trying to make available at least one city within each (sovereign, for some value of sovereign) country, to make selecting timezone as little confusing as possible. It is a lot easier for me, living in Norway, to understand that I should select Oslo for my timezone, and not Berlin (I would probably have ended up selected "Brussels", being the EU "capital", lacking other choices; Windows has a similar issue, I have never figure out which time zone I really am in from their list, as neither list my country/any cities in it). -- \\// Peter - http://www.softwolves.pp.se/
Date: Thu, 4 Aug 2022 01:12:15 +0100 From: Stephen Colebourne via tz <tz@iana.org> Message-ID: <CACzrW9CST5TAPdTQizL4G3GrGoCaO4rc-D6dtm-j0a80O3VNVQ@mail.gmail.com> | (I'd like to hear from Robert Elz as to whether he views the generated | tarballs as sufficient for NetBSD) Sorry, this was another message I had not read until just now... I probably would not have been able to answer anyway, as I don't think I had any easy way to test those changes until there was a release for me to fetch - they were only available in some git repo, I believe, and git (like emacs) is on my "stay away at all costs" list. I think over the past couple of messages, you can see the answer is "no". kre
Date: Wed, 3 Aug 2022 12:57:54 -0700 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <265e0d1d-9703-81bc-4bcc-ae27ec820be8@cs.ucla.edu> Sorry, I had a period when I didn't read any (or almost any) tz mailing list messages, just left them unread for later. That was particularly messages on this topic which I consider absurd really. Now is later (for some messages anyway) - I hadn't seen this message before. | On 7/8/22 13:14, Robert Elz wrote: | | > If the real reason for this is the workload of dealing with more zones, | > then simply acquire more helpers | | Would you like to be a helper? I'd be happy to delegate the job of | maintaining 'backzone' data. Not backzone as such - but if it were the same data in the files it belongs in, then sure. And: | In short, patches are welcome (please use git format-patch form). I don't use git, have never used git, and don't plan on ever doing so. So, that is unlikely to happen. On my system: jacaranda$ git clone anything -bash: git: command not found | Getting back to your comment, technical workload is not the main reason | to move data to 'backzone'. Politics are more important. For political | reasons many people care about data that are practically insignificant, | and these political concerns are a major long-term hazard to this | project. We're better off heading off these potential disputes at the | pass, by maintaining the database via nonpolitical guidelines and being | consistent about that, even if nobody has yet complained politically | about a particular data item. I have no problem with that as a general philosophy, but I prefer to do it by being inclusive, rather than exclusive - if someone has a reason to want a zone, which meets the guidelines, then create it. Why argue? The proposer would need to supply the data, and some evidence as to its veracity, but if they can do that, what is the problem? Fairly applying the guidelines is important of course. Certainly I have never been a proponent of specifying "one (or at least one) zone per country", rather I prefer "one zone for each authority that defines timezones" - which generally means the same thing in practice, as countries generally consider themselves sovereign, so anything that requires legal definition must be done somewhere in the country - but by avoiding use of the word, we can avoid the "are you a country?" and "who decides" issues. All that we'd require is evidence that there's someone setting the time in some region, which people in the area actually use (eg: Eucla ). Certainly none of the changes that have been made avoid any of the naming issues - the names exist whether just as a link or an actual zone. | Of course we cannot forestall all possible | political complaints; still, it's a win to be as nonpolitical as we | reasonably can. Yes, but you seem to be inventing potential complaints in order to make changes, without there being any real reason to believe that anything is being gained by this. | and the recently-installed tailored_tarballs | target[2] should suffice for Java-like downstream users. As you might have seen from my previous message (reply to a message from Stephen Colebourne) it doesn't do what we need, as we distribute the source (files) as well as TZif - they both need to contain the appropriate data (and users need to be able to simply update from one of the source files - get new versions of the zones it produces, and have the same results, modulo any changes they made, as the distributed versions). In this, also note that we do not use, or distribute, your Makefiles, NetBSD has a fairly rigorous set of Makefiles, which do (in a very minimalist way - making use of common makefile fragments) what is needed, and no more. We also use (and update) the tzcode and tzdata files separately (different maintainers in NetBSD). The data generally gets updated very quickly after it is released, or used to before it started needing manual manipulation - the code less frequently, as it needs to be merged with our changes. | In reading through the comments on this thread, nobody expressed an | opinion on the idea of finishing the move to 'backzone' now instead of | doing it in dribs and drabs. I wouldn't express an opinion on that, as I don't think any of the move to backzone is appropriate - not from the very earliest (except in those very very few cases where the zone should never have existed at all). I'd like to see all the data moved back where it belongs, and not have some of it being treated as first class, and other as no-class-at-all. kre
On 8/15/22 13:04, Robert Elz wrote:
I don't use git, have never used git, and don't plan on ever doing so. So, that is unlikely to happen.
Then perhaps you could come up with some other form for changes to the backzone data, and someone else who cares about backzone data could volunteer to put those changes into git format-patch form. There doesn't have to be a single person that does all the work. That being said, it's certainly fine if you don't want to bother. 'backzone' is a mess, it's unimportant to almost everybody, maintenance would be a thankless and time-consuming job, and everybody's better off spending their limited time doing other things.
the names exist whether just as a link or an actual zone.
Although that's true for old names, where at least a Link must be present for backward compatibility with the old guidelines, it's not true for the way things are done now. For example, despite recent events in Kosovo we haven't had to worry about creating a name like Europe/Pristina, and this is a win.
Date: Mon, 15 Aug 2022 13:45:20 -0700 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <d841baed-8aa1-708f-f653-3e409ddb93f8@cs.ucla.edu> | Then perhaps you could come up with some other form for changes to the | backzone data, and someone else who cares about backzone data could | volunteer to put those changes into git format-patch form. That might be possible, but I really don't understand, other than zealotry, why it is important. patch can handle all kinds of input. I cannot see that it should matter which form is used (though one with context is obviously better than one without). diff -u is our most common form. If you want git format to get the change log message, then from me, that's unlikely to help you - first because in non-compiled data (data not subject to automated checking) I tend to make all kinds of typos, which would need correcting, and second, because the kind of comments I would supply are unlikely to be the kind you'd be willing to commit. | That being said, it's certainly fine if you don't want to bother. | 'backzone' is a mess, it's unimportant to almost everybody, maintenance | would be a thankless and time-consuming job, I don't actually see many changes to data that's in backzone, and most of what does appears from people who have spent quite a bit of time researching the changes. | and everybody's better off | spending their limited time doing other things. I disagree. The README file that was (still, and unchanged) in that tar file you made available (at least known) in the previous message says: This database of historical local time information has several goals: * Provide a compendium of data about the history of civil time that is useful even if not 100% accurate. * Give an idea of the variety of local time rules that have existed in the past and thus may be expected in the future. * Test the generality of the local time rule description system. Those I think all remain important. Eg: as now being distributed Cambodia claims to have used UTC+0700 since 1921. But that's not what the old Asia/Phnom_Penh zone said, with timezone changes in the WWII period. Now the precise details of the changes listed might or might not be correct, but pretending that no zone change happened at all is much less correct (unless you have some evidence that's true, which I doubt). | For example, despite recent events | in Kosovo we haven't had to worry about creating a name like | Europe/Pristina, and this is a win. I don't recall seeing anyone request one, which is one reason for not creating it - but if they did, I believe you should. I certainly don't see failing to create it as any kind of win. I understand the argument - the guidelines say there is no need for a new zone as the time has been the same as ... since at least 1970. And you can claim that you're not making a political decision because of that - though people in Kosovo might (one day) start complain that you're a Russian/Serbian puppet, and are trying to pretend Kosovo doesn't exist. Now understand that I'm not claiming that my version of the guidelines would make much difference in this area - but as Kosovo clearly has a government, who are capable of choosing what timezone they're in (and as not EU members, or not currently anyway, they're not even restricted by EU policies), so under my proposal, they'd get a zone if they asked for one. Of course, to their opponents, that would mean that you're adopting the Kosovo side of their dispute, you're just a US puppet, and proclaiming that everything is biased against them. That is, there is no avoiding of political controversy here, act, don't act, you're always going to anger the people who wanted the other decision. Or in other words, "avoiding political issues" simply doesn't work. What you're really saving is 15 minutes editing and testing now, and deferring it to sometime later, when they decide to change their zone rules, and a new zone is necessary, but at this point it becomes a harder transition for everyone (everyone else anyway) as people who would logically have been using Europe/Pristina (and could have switched to that from whatever they have been using, whenever they felt inclined, since both would have generated the same results - at least post 1970) would then all have to switch in a hurry, to get the modified zone in time for the change to take effect. Not nice to inflict on people for no good reason. This is exactly the same as when you said that we won't tell people in Sweden to switch to using Europe/Berlin (though that's effectively what you are doing to them) so things are easier if they Sweden and Germany separate their zones (like one keeping summer time, and the other not). That's fine for the Swedes (though dropping their historical data is not), but why are the people in Kosovo not afforded the same courtesy? kre
Robert Elz wrote in <10948.1660601685@jacaranda.noi.kre.to>: | Date: Mon, 15 Aug 2022 13:45:20 -0700 | From: Paul Eggert <eggert@cs.ucla.edu> | Message-ID: <d841baed-8aa1-708f-f653-3e409ddb93f8@cs.ucla.edu> ... |This database of historical local time information has several goals: | | * Provide a compendium of data about the history of civil time that | is useful even if not 100% accurate. What i do not understand is that: if the latter is true, then why do you all not simply include backzone, and be fine with it? It surely is the best there is, and the one or two entries which seem ambiguous because different sources claim different things (or the same source does so), one had be chosen to be included. That is all there can be done about that. And post 1970 it makes no difference. End of the story. | * Give an idea of the variety of local time rules that have existed | in the past and thus may be expected in the future. | | * Test the generality of the local time rule description system. | |Those I think all remain important. Eg: as now being distributed |Cambodia claims to have used UTC+0700 since 1921. But that's not |what the old Asia/Phnom_Penh zone said, with timezone changes in the |WWII period. Now the precise details of the changes listed might or |might not be correct, but pretending that no zone change happened at |all is much less correct (unless you have some evidence that's true, |which I doubt). I think i spoke for Laos in 2014 when the first such change happened. I fail to see a difference in between Laos, Cambodia, and what recently happened, except for skin colour and military and economical power, thus also prerogative of interpretation. ("A thing like never before", maybe even. To have it said.) To have it said. I would not have done it, but then it was done and noone cared no more. So it should be completed. You can use zone.tab instead of zone1970.tab with tzselect, unfortunately it is an undocumented option. Is this mischievous? If you want it all, include backzone. Change the default to zone.tab, this is an easy packager decision. They are both installed in a default installation ever since, at your fingertip. "We didn't start the fire, it was always burning." You are concerned, you are an expert maintainer, do these two things. If i look around what packagers do to get their things done, local patches and what not. Packagers i do not understand at all. Things are different for source consumers, they have a harder time. But -- the change was made in 2014! This is eight years! This is all you who happily agree with strange code of conducts, changing master to main, black to block, white to allow, red to green, yellow to spots in the snow, and what not. No no. Can't you source consumers simply generate the full tzdata.zi on your local box, and write an awk script that turns that one into an input file of your application? Remove the rest of your toolchain? What is it that makes it so hard? Now that at least some of you provide their own tarball for TZ? I really do not understand. || For example, despite recent events || in Kosovo we haven't had to worry about creating a name like || Europe/Pristina, and this is a win. | |I don't recall seeing anyone request one, which is one reason for |not creating it - but if they did, I believe you should. I certainly |don't see failing to create it as any kind of win. | |I understand the argument - the guidelines say there is no need for |a new zone as the time has been the same as ... since at least 1970. |And you can claim that you're not making a political decision because |of that - though people in Kosovo might (one day) start complain that |you're a Russian/Serbian puppet, and are trying to pretend Kosovo doesn't |exist. Others may say you seem to confuse cause and effect. It is all very sensitive. |Now understand that I'm not claiming that my version of the guidelines |would make much difference in this area - but as Kosovo clearly has a |government, who are capable of choosing what timezone they're in (and as |not EU members, or not currently anyway, they're not even restricted by |EU policies), so under my proposal, they'd get a zone if they asked \ |for one. | |Of course, to their opponents, that would mean that you're adopting the |Kosovo side of their dispute, you're just a US puppet, and proclaiming |that everything is biased against them. | |That is, there is no avoiding of political controversy here, act, don't |act, you're always going to anger the people who wanted the other decision. | |Or in other words, "avoiding political issues" simply doesn't work. | |What you're really saving is 15 minutes editing and testing now, and |deferring it to sometime later, when they decide to change their zone |rules, and a new zone is necessary, but at this point it becomes a |harder transition for everyone (everyone else anyway) as people who would |logically have been using Europe/Pristina (and could have switched to that |from whatever they have been using, whenever they felt inclined, since |both would have generated the same results - at least post 1970) would |then all have to switch in a hurry, to get the modified zone in time for |the change to take effect. Not nice to inflict on people for no good \ |reason. | |This is exactly the same as when you said that we won't tell people in |Sweden to switch to using Europe/Berlin (though that's effectively what |you are doing to them) so things are easier if they Sweden and Germany |separate their zones (like one keeping summer time, and the other not). |That's fine for the Swedes (though dropping their historical data is not), |but why are the people in Kosovo not afforded the same courtesy? | |kre --End of <10948.1660601685@jacaranda.noi.kre.to> --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 8/15/22 15:14, Robert Elz wrote:
patch can handle all kinds of input.
Sure, and 'patch' often goofs up - which is partly my fault as I am one of the three maintainers for 'patch'. Plus, 'patch' is just part of the job. Often the commit message is just as important as the actual change. 'git format-patch' and 'git am' handle this nicely; 'patch' does not. I want to minimize work evaluating and installing patches to out-of-scope parts of tzdb. This is not an unreasonable request. If you don't want to use 'git' that's fine; somebody else can do that part of the work, if maintaining 'backzone' is important to enough people.
in non-compiled data (data not subject to automated checking) I tend to make all kinds of typos, which would need correcting, and second, because the kind of comments I would supply are unlikely to be the kind you'd be willing to commit.
It's OK if typos are limited to 'backzone' as it has unimportant data. Plus, you can always fix any typos later, whenever you get around to it. As for comment format let's see what sorts of comments you write: if others who care about 'backzone' don't care about the comments then I'm not likely to care either.
| For example, despite recent events | in Kosovo we haven't had to worry about creating a name like | Europe/Pristina, and this is a win.
I don't recall seeing anyone request one
Here's one example: https://mm.icann.org/pipermail/tz/2014-January/020589.html
Date: Mon, 15 Aug 2022 16:21:52 -0700 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <47967be4-875f-368b-54a0-580a5d96703d@cs.ucla.edu> | Sure, and 'patch' often goofs up - which is partly my fault as I am one | of the three maintainers for 'patch'. I don't think I have ever seen patch, when given any of the forms of context diff, "goof up" - unless you include not being able to apply the patch (because the context of the source has changed since the patch was created) as such a goof - I don't. It does odd things sometimes in non-context forms, when it is relying on just line numbers to identify where the patch goes. That only works (can only be expected to work) when the base file has not altered at all. | Plus, 'patch' is just part of the job. Often the commit message is just | as important as the actual change. 'git format-patch' and 'git am' | handle this nicely; 'patch' does not. Yes, but it was that which I was referring to here: | > in non-compiled data (data not subject | > to automated checking) I tend to make all kinds of typos, which would | > need correcting, and second, because the kind of comments I would supply | > are unlikely to be the kind you'd be willing to commit. Not to the data that would be being put into the file, which would not be ... | It's OK if typos are limited to 'backzone' as it has unimportant data. that one, as I will only do this if the data goes back in the files from where it has been removed (those are what I work with), and in any case, none of the data is unimportant, whatever file it happens to be placed in. Separating out the data, and just having the mindset that some of it is unimportant, is what leads to problems like the issues that Bradley White identified with 2022b/2022c. But back to the point, it is the commit message that would likely have lots of typos (look at some of my commits to NetBSD - the log messages are full of stuff like that, unfortunately), and most likely also have comments that you are unlikely to want to have stored in the git history of the data. You'd not be saving any work by getting a git format patch from me, probably actually adding steps. | Plus, you can always fix any typos later, whenever you get around to it. | As for comment format let's see what sorts of comments you write: if | others who care about 'backzone' don't care about the comments then I'm | not likely to care either. So, that's not relevant - unless git allows the log entries to be revised, in which case, that's just one more strike against git. Obviously the data in the file (whether that be data that zic processes, or comments) is subject to later revision, that didn't need saying. | > | Europe/Pristina, and this is a win. | > I don't recall seeing anyone request one | Here's one example: | https://mm.icann.org/pipermail/tz/2014-January/020589.html It is no wonder I did not remember that, but neither that short thread, nor the one from May 2013, really amount to a request to add the zone - more a "I wonder if we should be adding ..." type thing. The earlier discussion seemed to be most concerned about whether Kosovo is a country or not, which is irrelevant to me (I'm sure it is important to many people, but I'm not one of them, and it should never be important here either - fine to add an assigned country code if it has one, but even if it doesn't, it still has time). With hindsight, back then would probably have been a good time to at least create the zone name as a link. I certainly don't see any problems doing so would have caused (beyond the normal extra effort creating any new zone requires.) kre
On 8/17/22 04:02, Robert Elz wrote:
I don't think I have ever seen patch, when given any of the forms of context diff, "goof up" - unless you include not being able to apply the patch (because the context of the source has changed since the patch was created) as such a goof - I don't.
Even when context matches, I've seen 'patch' apply changes in the wrong place due to the file having two places with similar context. Admittedly this happens only when we're doing the equivalent of merging branches, but it can happen. More important, sending diffs via email is notoriously dicey due to email software messing with white space. One can get around this problem by attaching diffs rather than sending them inline, but this is more hassle for the reader. Still more important, diff output doesn't address the problem of the commit message, something I mentioned in my earlier email. And now that I think about it, diff output also lacks author and timestamp info. Although I could work around these problems by hand, that'd be make-work, which is why I'm asking for 'git format-patch' form. This form was designed after a lot of experience with the abovementioned problems, and it's a better design in pretty much every respect. Although you don't want to use Git, I hope this explains why I want git format-patch form. Perhaps you can write some code to generate the right form without using Git, or find someone else to volunteer to use Git to generate the desired form. This issue is not unique to Git, as I often deal with other projects with preferences about patch format. Most prefer Git which is not surprising as Git is #1 in this space now. A few, though, use Subversion, or Mercurial, CVS (!), or even "diff -c" (!!) and I send patches in the form they prefer.
Separating out the data, and just having the mindset that some of it is unimportant, is what leads to problems like the issues that Bradley White identified with 2022b/2022c.
Those issues didn't affect in-scope data, and so they are important only to those who think that 'backzone' is important. Such people can, if they like, step up to maintain 'backzone' and deal with the inevitable make-work and political flames. (I should warn, though, that Bradley White merely reported the tip of the iceberg of backzone's problems.) Again, I don't advise you or anybody else to take up the task of maintaining 'backzone' - your limited time is better spent elsewhere. But if you want to do it despite my advice, please feel free.
But back to the point, it is the commit message that would likely have lots of typos (look at some of my commits to NetBSD - the log messages are full of stuff like that, unfortunately), and most likely also have comments that you are unlikely to want to have stored in the git history of the data.
There are some limits to commit messages. We shouldn't install anything that infringes copyright, defames, contains pornography, etc. But let's not worry about ordinary mistakes in commit messages. Lots of TZDB's commit messages already have uncorrected mistakes. That's OK.
You'd not be saving any work by getting a git format patch from me, probably actually adding steps.
For this sort of thing all I want to do is to either (1) say "The patch isn't right; please fix and resubmit" or (2) install the patch as-is. The idea is for us to get used to the process so that (1) is rare. If that can't be arranged then let's not bother.
unless git allows the log entries to be revised
It doesn't. That is, Git doesn't let you change any part of any commit. At most one can create a different commit (with a different commit ID) and remove the old commit, but I have never done that to TZDB despite many mistakes in commit messages. I would do such a thing only if a copyright infringement etc. somehow sneaked into the repository, which I hope never happens.
| > | Europe/Pristina, and this is a win. | > I don't recall seeing anyone request one
| Here's one example: | https://mm.icann.org/pipermail/tz/2014-January/020589.html
It is no wonder I did not remember that, but neither that short thread, nor the one from May 2013, really amount to a request to add the zone
Although I interpreted that as a request to add Europe/Pristina, that's no big deal, as whoever's maintaining 'backzone' can interpret such requests. I have also gotten private emails on the topic, emails that I'd rather not redistribute; if people step up to maintain 'backzone' we can ask requesters to correspond with the 'backzone' maintainers about out-of-scope data like that.
Robert Elz via tz said:
| For example, despite recent events | in Kosovo we haven't had to worry about creating a name like | Europe/Pristina, and this is a win.
I don't recall seeing anyone request one, which is one reason for not creating it - but if they did, I believe you should. I certainly don't see failing to create it as any kind of win.
I understand the argument - the guidelines say there is no need for a new zone as the time has been the same as ... since at least 1970. And you can claim that you're not making a political decision because of that - though people in Kosovo might (one day) start complain that you're a Russian/Serbian puppet, and are trying to pretend Kosovo doesn't exist.
So why doesn't that argument apply to Europe/Glasgow and Europe/Cardiff? Followed in quick succession by Europe/Redruth. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
So why doesn't that argument apply to Europe/Glasgow and Europe/Cardiff?
Followed in quick succession by Europe/Redruth.
Oops, should it be Europe/Caerdydd and Europe/Rhydruth? -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On Wed, Aug 17, 2022 at 4:57 AM Clive D.W. Feather via tz <tz@iana.org> wrote:
So why doesn't that argument apply to Europe/Glasgow and Europe/Cardiff?
Followed in quick succession by Europe/Redruth.
Noe Europe/Resrudh? Why would you name a Cornish town in Welsh and not Kernowek? (And that will get you into the question of whether you count metropolitan area or corporation limits, because it's Redruth if you count one way and Falmouth if you count the other) We now return you to your regularly-scheduled political squabble. -- 73 de ke9tv/2, Kevin
Kevin Kenny said:
> Followed in quick succession by Europe/Redruth.
Noe Europe/Resrudh? Why would you name a Cornish town in Welsh and not Kernowek?
Because we use English representations of "city" names. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
Date: Wed, 17 Aug 2022 09:27:20 +0100 From: "Clive D.W. Feather" <clive@davros.org> Message-ID: <YvymaGwHvtqcbZtY@davros.org> | So why doesn't that argument apply to Europe/Glasgow and Europe/Cardiff? Glasgow most probably should have a zone, I'm not aware enough of the political situation of Wales to guess whether one for Cardiff (however you want to spell it...) would ever actually set the timezone, or even have the capacity to do so, but I have no objection to it in principal. | Followed in quick succession by Europe/Redruth. I have absolutely no idea where that is, or what it is, so no comment. The decision would be based generally on whether the authority in question has the authority to set the time (which would be demonstrated by their having done that, even if that amounts to no more than "The English Standard time act of 1317 applies, as amended, including amendments made in the future".) or has demonstrated actually setting the timezone and having that used. If all the data for the zone (back to the beginning of standard time) is the same as that of some other zone (LMT not counted, as that only ever applies at one point, the offset needs to be recalculated based on longitude everywhere else - not that anyone ever bothers doing that) then it can be implemented as just a link (until such time as it differs). kre
Robert Elz said:
| So why doesn't that argument apply to Europe/Glasgow and Europe/Cardiff?
Glasgow most probably should have a zone, I'm not aware enough of the political situation of Wales to guess whether one for Cardiff (however you want to spell it...) would ever actually set the timezone, or even have the capacity to do so, but I have no objection to it in principal.
| Followed in quick succession by Europe/Redruth.
I have absolutely no idea where that is, or what it is, so no comment.
It's the largest town in Kernow.
The decision would be based generally on whether the authority in question has the authority to set the time (which would be demonstrated by their having done that, even if that amounts to no more than "The English Standard time act of 1317 applies, as amended, including amendments made in the future".) or has demonstrated actually setting the timezone and having that used.
So if I can get a group the rest of my street to agree that I have set the time they use (even if it follows the same rules as the rest of the UK), then I can have my own time zone? Or, if you don't like that example, my parish council. Actually, that would probably be easier than my street; it's about the same size and I could do some political horse-trading. What stops any state in the US legislating that their time is the same as the time set by Congress and then claiming a new zone? Or any county (for those states that have them)? I'm not sure what the right answer is for pre-1970 data, and we need to keep alive the names of any zones we've had in the past, but I'm firmly in the "one zone for each geographical area that keeps the same time, irrespective of any other political boundaries" camp. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
Date: Wed, 17 Aug 2022 12:00:09 +0100 From: "Clive D.W. Feather" <clive@davros.org> Message-ID: <YvzKOeicNWFrPM/l@davros.org> | It's the largest town in Kernow. As I assume you expected, that doesn't help a lot (that is, not at all)! | So if I can get a group the rest of my street to agree that I have set the | time they use (even if it follows the same rules as the rest of the UK), | then I can have my own time zone? If your group has the authority to do that, then yes. That's why my version of the guidelines (which would still need more precision) specify having the authority, or having actually set a timezone. That's why I gave different results for Glasgow and Cardiff - my assumption (which might be wrong, certainly) is that the Scottish parliament has the power to set time, I'm not even sure Wales has an equivalent body, and if it has, my guess is that it is able to do much less (Wales has been subservient to England for far longer than Scotland has, I believe). | What stops any state in the US legislating that their time is the same as | the time set by Congress and then claiming a new zone? Or any county (for | those states that have them)? I don't know enough about the US political situation to judge. But 45 new zones (or whatever it ends up being) most of which would be identical to one of the existing 5 or 6 (however many there are) would not be all that bad. Not that I would expect that to happen, as from what I can determine, people in the US consider themselves in Eastern/Central/Mountain/ Pacific timezones (plus whatever applies in Hawaii and Alaska) and that's what they expect to exist. In Australia time is ruled by the states (and territories) and people expect each to be its own timezone. That the ACT (Canberra) timezone is inconceivable in practice to ever be different from that of NSW (Sydney) is more or less irrelevant. If Australia had had 50 states instead of 6, I expect it would have 50 zones. In Thailand, the thought that anyone can define the time is probably not something people consider, but certainly only the national govt would have that ability, not the Changwat (states) or smaller divisions. kre
Robert Elz said:
| It's the largest town in Kernow. As I assume you expected, that doesn't help a lot (that is, not at all)!
It's my point. Kernow is the Cornish name for Cornwall, another part of the UK that has an independence movement.
| So if I can get a group the rest of my street to agree that I have set the | time they use (even if it follows the same rules as the rest of the UK), | then I can have my own time zone?
Sorry, bad editing. That should have just said "So if I can get the rest of my street to agree ...".
If your group has the authority to do that, then yes.
But define "authority". My authority starts and ends when people accept what I say.
That's why my version of the guidelines (which would still need more precision) specify having the authority, or having actually set a timezone.
Chicken and egg. If I set a timezone, just as how you suggested, then do I get my own zone name?
That's why I gave different results for Glasgow and Cardiff - my assumption (which might be wrong, certainly) is that the Scottish parliament has the power to set time, I'm not even sure Wales has an equivalent body, and if it has, my guess is that it is able to do much less (Wales has been subservient to England for far longer than Scotland has, I believe).
Wales has an Assembly which has less powers than Scotland. Neither, I think, has time zones in its official remit.
| What stops any state in the US legislating that their time is the same as | the time set by Congress and then claiming a new zone? Or any county (for | those states that have them)?
I don't know enough about the US political situation to judge. But 45 new zones (or whatever it ends up being) most of which would be identical to one of the existing 5 or 6 (however many there are) would not be all that bad.
What about counties? There are apparently 3006 counties and 137 county equivalents. How do you fancy 3143 new zones?
In Australia time is ruled by the states (and territories) and people expect each to be its own timezone.
Is Eucla a state or a territory? What authority did it have?
In Thailand, the thought that anyone can define the time is probably not something people consider, but certainly only the national govt would have that ability, not the Changwat (states) or smaller divisions.
What about China? What authority was Asia/Urumqi created under? Or is it just common usage? -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
Date: Wed, 17 Aug 2022 18:39:27 +0100 From: "Clive D.W. Feather" <clive@davros.org> Message-ID: <Yv0nzw98wLr7M5m+@davros.org> | It's my point. Not much of a point, there are lots of places, including places with their own timezones, that I've never heard of, and other than the region prefix of the timezone identifier, I have no clue where they are. Express any of that in the local languages (whether encoded in latin script or not) and there would be lots more. | Kernow is the Cornish name for Cornwall, another part of the UK that has an | independence movement. OK, but having an independence movement isn't relevant. Achieving independence (whether recognised as legitimate by other bodies or not) would. Otherwise it would require explicit granting of power to set the time, or obviously possessing that power, or actually doing it (and that means changing the zone, not just saying "I could do it if I wanted to, but it happens I don't"). | But define "authority". My authority starts and ends when people accept | what I say. Sure. But you need to demonstrate that it exists, not just claim it. And once again, that can be by demonstrating the legal chain of grants of power from some body already accepted to have it (for you, that would be the British Parliament, or maybe the Crown in some bizarre circumstance) or by demonstrating your influence by actually having your street run their clocks at some different time offset than they're supposed to legally. | > That's why my | > version of the guidelines (which would still need more precision) specify | > having the authority, or having actually set a timezone. | | Chicken and egg. If I set a timezone, just as how you suggested, then do I | get my own zone name? If you really create a different timezone, then yes. I think that is already accepted. But just saying that your street runs on High Street Time (HST) rather than UTC/GMT/BST and it happens that HST is the same as UTC during winter, and UTC+0100 during summer, and just by coincidence the changes happen at just the same time as the EU (and Britain) say they happen is not creating a timezone. That's just grandstanding. So you have two possibilities, you actually get a big enough set of people (at the very least a majority in the area) to actually live and work (which includes post office opening/closing times, bus timetables, parking restrictions, ... everything else which uses the time) to use your different offset from UTC, which would demonstrate your ability to control the time in your area, or you have the British Parliament pass an act delegating control of the time in High Street wherever to Clive Feather (or the High Street Timelords, of which you're president, or whatever) so you can show you have the legal ability to set the time, should you desire to. Or I guess as a third choice, you could take up arms against Britain, and win control of your street (and some surrounds, so there are people involved, not just asphalt) set up border control posts, and start issuing your own passports, collecting taxes, ... - and remain in that position long enough that anyone might take a breath long enough to consider timezone issues. | Wales has an Assembly which has less powers than Scotland. That's about what I thought. I assume Cornwall has even less. | Neither, I think, has time zones in its official remit. That surprises me a little about Scotland, but I'm in no position to know. But in that case, to get an entry in tzdb they'd need to change the time. I can almost imagine Scotland doing that, they're almost too far north for summer time to make a lot of sense I think (too high, or too low, a latitude and the idea is silly - it really works well only in the middle latitudes). So, Scotland could cancel summer time, and England retain it, then there would need to be a Europe/Glasgow (I'm assuming Glasgow is bigger than Edinburgh, not claiming that to be true). | What about counties? There are apparently 3006 counties and 137 county | equivalents. How do you fancy 3143 new zones? If necessary, and if someone gives them the authority to set their own times, then why not? We already know from the Indiana examples that if they actually run with a different offset they're going to get a different zone, and that if some parts of Mountain time decide to adopt "permanent DST" (which is a ludicrous concept as a name) and others don't, that there will be a new zone created (there must be). There's nothing we can do to limit this. Simply refusing to give someone with the obvious ability to change the time, a tzdb entry if they want one will only serve to have them change the time in their area for the sole purpose of getting an entry. After all, all that's required for that is to begin, or end, summer time an hour earlier or later than others do, for one year, and you're different. Or perhaps gradually work into summer time, by putting the clocks forward 15 minutes at 01:00, another 15 minutes at 02:00, a further 15 minutes at 03:00, and finish the process at 04:00 (all times local wallclock time in the zone). That is, the periods 01:00:00..01:14:59 would not exist, nor would 02:00:00..02:14:59 (etc) - and this they only need to try for one year, to see if it works. New zone. I don't think it is a good idea to encourage that kind of idiocy, do you? The current rules do. | Is Eucla a state or a territory? What authority did it have? Eucla is a town (quite a small town) in Western Australia, not far from the border with South Australia (which makes it a long way from anywhere). Its authority is its demonstrated ability to run its time as it sees fit. But if you're implying that most people in Aust wouldn't expect Eucla to have its own timezone, then I think you're right. I suspect most people in Australia have never heard of Eucla. Yet they do have a timezone (and correctly). | What about China? What authority was Asia/Urumqi created under? Or is it | just common usage? I don't know details, but I'd assume similar to Eucla - a long way from anywhere, and far enough away from what is the legal timezone (further than Eucla I believe) that using it would be inconvenient - so they use something else. Whether they have some organisation which decided that, or it is just the way it always has been, and the local people simply ignore the demands of the central govt to change I have no idea. Nor does it matter, what matters is that people there (not necessarily all, but enough, apparently, though I have no knowledge nor sources to confirm that) actually use a different time than is used in Shanghai (and Beijing, Guangzhou, etc). If your street does that (if you can convince your neighbours, and local shops, to run their clocks differently - apply parking, banking, ... hours according to your own vision of how things should be) then you should be able to get a zone as well. Similarly if you show you have the legal ability to mandate such a change, should you desire it ... just so if that happens, your neighbours' clocks (the intelligent ones anyway - clocks I mean, not neighbours) will adjust all by themselves, without needing manual intervention. kre
On Aug 17, 2022, at 2:22 PM, Robert Elz via tz <tz@iana.org> wrote:
On Aug 17, 2022, at 18:39:27 +0100, "Clive D.W. Feather" <clive@davros.org> wrote:
Is Eucla a state or a territory? What authority did it have?
Eucla is a town (quite a small town) in Western Australia, not far from the border with South Australia (which makes it a long way from anywhere). Its authority is its demonstrated ability to run its time as it sees fit.
But if you're implying that most people in Aust wouldn't expect Eucla to have its own timezone, then I think you're right. I suspect most people in Australia have never heard of Eucla. Yet they do have a timezone (and correctly).
From what I've been able to find, that's *not* an official time zone in the sense of the Australian government or the government of the state of Western Australia having enacted it into law: https://www.australia.gov.au/time-zones-and-daylight-saving but the Shire of Dundas acknowledged its existence in page 7 of their 2012-2013 annual report: https://web.archive.org/web/20150304074421/http://www.dundas.wa.gov.au/Asset... and apparently there are road signs that acknowledge it. https://archive.ph/20160505150909/http://basementgeographer.com/central-west...
What about China? What authority was Asia/Urumqi created under? Or is it just common usage?
I don't know details, but I'd assume similar to Eucla
That, on the other hand, has some central government authority behind it: https://web.archive.org/web/20061114120456/http://www.pep.com.cn/200503/ca69... Google Translate doesn't handle that, but the translator in macOS Big Sur's Safari does, giving Legal hours and Beijing time The time zone system is ideal, but when used by countries around the world, they use the time of different time zones as statutory time according to their geographical, economic and political conditions, because this time and its scope of application are usually formulated and promulgated by decree by national legislature or government authorities. Most of the standard longitude used in statutory time is also the standard longitude of regional time, but there are also standard longitude in many countries, which is very different from the standard longitude of regional time. Beijing time is not the local time in Beijing, but refers to the time of the Eastern Eighth District. It is a unified time zone defined by China administratively for all parts of the country, which is commonly referred to as "Beijing time". The difference between Beijing time and Beijing is 14m44s. China regards the Eastern Eighth District Time as the legal time, which is formulated in accordance with the principle of east. This is done to use time earlier than the actual local time to make full use of sunlight. With the approval of the relevant state departments, the Xinjiang Uygur Autonomous Region has implemented "Xinjiang Time" since February 1986, that is, the time of the eastern 6 districts; locally known as "Urumqi time", which is mainly used for civil work and rest time. Railways, civil aviation, post and telecommunications departments still use Beijing time. (are they really saying that the time in Beijing is solar time rather than Beijing time?). although apparently many Han Chinese in the region don't like that and keep Beijing time: https://en.wikipedia.org/wiki/Xinjiang_Time
On 17 Aug 2022, at 22:22, Robert Elz via tz <tz@iana.org> wrote:
Date: Wed, 17 Aug 2022 18:39:27 +0100 From: "Clive D.W. Feather" <clive@davros.org> Message-ID: <Yv0nzw98wLr7M5m+@davros.org>
| Wales has an Assembly which has less powers than Scotland.
That's about what I thought. I assume Cornwall has even less.
| Neither, I think, has time zones in its official remit.
That surprises me a little about Scotland, but I'm in no position to know.
You are now. :-) The powers of the Scottish Parliament are defined by the Scotland Act 1998. The basic principle is that it can legislate for anything that isn't a "reserved matter" (section 29). Schedule 5 of the Act sets out these reserved matters. They include "Timescales, time zones and the subject-matter of the Summer Time Act 1972." See: <https://www.legislation.gov.uk/ukpga/1998/46/schedule/5#schedule-5-part-II-c...> Peter Ilieve
Robert Elz said:
| It's my point.
Not much of a point, there are lots of places, including places with their own timezones, that I've never heard of, and other than the region prefix of the timezone identifier, I have no clue where they are. Express any of that in the local languages (whether encoded in latin script or not) and there would be lots more.
| Kernow is the Cornish name for Cornwall, another part of the UK that has an | independence movement.
OK, but having an independence movement isn't relevant. Achieving independence (whether recognised as legitimate by other bodies or not) would. Otherwise it would require explicit granting of power to set the time, or obviously possessing that power, or actually doing it (and that means changing the zone, not just saying "I could do it if I wanted to, but it happens I don't").
On Tuesday you wrote: | if someone has a reason to | want a zone, which meets the guidelines, then create it. Why argue? | The proposer would need to supply the data, and some evidence as to its | veracity, but if they can do that, what is the problem? | All that we'd require is evidence that there's someone setting the time | in some region, which people in the area actually use And I've been working with that.
| But define "authority". My authority starts and ends when people accept | what I say.
Sure. But you need to demonstrate that it exists, not just claim it. And once again, that can be by demonstrating the legal chain of grants of power from some body already accepted to have it (for you, that would be the British Parliament, or maybe the Crown in some bizarre circumstance) or by demonstrating your influence by actually having your street run their clocks at some different time offset than they're supposed to legally.
Why does it need to be different? Yesterday you wrote: | The decision would be based generally on whether the authority in question | has the authority to set the time (which would be demonstrated by their | having done that, even if that amounts to no more than "The English | Standard time act of 1317 applies, as amended, including amendments made | in the future".) So if I sit down and write that, and one other person says that's what they're using to set their watch, then I have demonstrated that I'm an authority. Right?
If you really create a different timezone, then yes. I think that is already accepted. But just saying that your street runs on High Street Time (HST) rather than UTC/GMT/BST and it happens that HST is the same as UTC during winter, and UTC+0100 during summer, and just by coincidence the changes happen at just the same time as the EU (and Britain) say they happen is not creating a timezone. That's just grandstanding.
Yes. But it's what you've been saying. You need to actually define "authority", at which point you're smack bang back into politics, which is what we need to avoid. You also need to demonstrate where Eucla gets its "authority" from and why I don't have the same "authority". Unless you're basing it *ONLY* on the fact that time in real use is different. At which point you're agreeing with my position.
Or I guess as a third choice, you could take up arms against Britain, and win control of your street (and some surrounds, so there are people involved, not just asphalt) set up border control posts, and start issuing your own passports, collecting taxes, ... - and remain in that position long enough that anyone might take a breath long enough to consider timezone issues.
I don't know what time Sealand, the world's smallest micronation, runs on, but it meets that description.
Simply refusing to give someone with the obvious ability to change the time, a tzdb entry if they want one will only serve to have them change the time in their area for the sole purpose of getting an entry.
But you're going in circles. You're saying that someone demonstrates they can change the time by changing the time.
I don't think it is a good idea to encourage that kind of idiocy, do you? The current rules do.
We don't seem to have had that problem so far. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
Date: Thu, 18 Aug 2022 15:38:26 +0100 From: "Clive D.W. Feather" <clive@davros.org> Message-ID: <Yv5O4iwq0A5stFUp@davros.org> | On Tuesday you wrote: Yes. | | All that we'd require is evidence that there's someone setting the time | | in some region, which people in the area actually use | | And I've been working with that. But you've done nothing which would provide any believable evidence. Do you believe that I control the time in the UK, merely because I recite a copy of the UX time acts and claim that I hereby annouce that by my authority that is the time in the UK? Even if I demonstrate that everyone (or almost all of them) are actually setting the clocks the way that I said they should? That's absurd. So were your examples. On the other hand, when the British parliament does exactly what I just said I could do, we do accept that they control the time in the UK. Do you see any difference between the two? | Why does it need to be different? Because that's one of the ways that you can demonstrate that the people using you as the authority for the time are actually doing that (actually, that it is you is irrelevant, tzdb zones define the fact of a timezone being in use, not its origins, except maybe in some comments). Otherwise we're likely to assume that your street are using British time because it is British time, legislated by Parliament, and not because you said that your street should do so, don't you think? | So if I sit down and write that, and one other person says that's what | they're using to set their watch, then I have demonstrated that I'm an | authority. Right? No. You can get people to say almost anything, if it seems harmless for them to do so, particularly if there's some kind of reward involved. You need to get them to do something different than they would otherwise do. To take an analogous example from another field. Say you're at a magic show, and there's one of those stage hypnotists. He (or she) proceeds to prove that they can hypnotise people, and does that with the usual swinging whatever which the audience is instructed to watch, along with the usual soothing banter. The hypnotist then proclaims the whole audience is now hypnotised, and instructs everyone to remain for as much of the rest of the show as they like, then leave, and go on with their life as normal. And everyone does. Proof of hypnosis working? Does it change anything if someone from the audience claims that yes, they were hypnotised? | > That's just grandstanding. | Yes. But it's what you've been saying. No, it isn't, it is the way you have been misinterpreting what I am saying. Perhaps I'm not as clear as I could be (many of these messages originate in the early hours of the morning, I'm half asleep already). | You need to actually define "authority", Yes, that's what I am trying to do. | at which point you're smack bang | back into politics, which is what we need to avoid. That's impossible. All politics means in this sense is that people disagree about what is right. Doesn't matter what the rules are, some people will either disagree with the rule, or with its application. I do understand that some people cannot tolerate being asked to justify a decision they have made, so can only operate when in an environment where there are rules that tell them exactly what they have to do at every step, and leave no room at all for discretion. That's what usually leads to abominable operations, as it is very rare for anyone to be able to imagine all the possible future scenarios that may arise when they write the rules, and leads to "it's no-one fault, everyone did what they were supposed to do, it is just the system" type excuses for abject failure. That's not the kind of thing I feel inclined to be a part of. | You also need to demonstrate where Eucla gets its "authority" from and why | I don't have the same "authority". You do. They changed the time they operate in, that's the demonstration of their authority (and it has lasted decades). All you need to do is do the same thing. | Unless you're basing it *ONLY* on the fact that time in real use is | different. At which point you're agreeing with my position. No, that's one way to demonstrate authority. As I understand it, Eire and the UK operate under the same timezone rules, right? From that would you accept (would anyone) that Eire is under the authority of the British Parliament? (or vice versa). That is, that because the times are the same there must be just one authority? They each clearly have the authority to alter the time if they see fit. All countries do, or almost all, Australia doesn't in general, the Australian states do instead. Maybe there are others like that. There is more than one kind of authority. Similarly whether you regard Palestine or Kosovo (or others similar) as countries or not, it is clearly indisputable that they have the authority to alter the time in their region of control. Palestine has done do (I think) Kosovo has not. That alters nothing - they could, and we know they could - which means giving them a zone prepares everyone for when that happens, if it does, and does not require endless end stations to be reconfigured, just updated. | I don't know what time Sealand, the world's smallest micronation, runs on, | but it meets that description. Then we give it a tzdb entry. | But you're going in circles. You're saying that someone demonstrates they | can change the time by changing the time. No, I am not. I was talking (writing) mostly about how you would do it in your street, and I think I might have once said that your other option was to have the British Parliament delegate control over the time in your street, to you - that would be another way to get a Europe/Dalek_High_Street zone created, without actually changing the time. Good luck. | > I don't think it is a good idea to encourage | > that kind of idiocy, do you? The current rules do. | We don't seem to have had that problem so far. No, we don't - but that's largely because (almost) everyone able to control the time has a zone already. That's because of the (now abandoned apparently) policy that all countries get at least one zone. (IMO countries never was the right designation, that invites other peoples problems to descend upon us, which we don't need - but something to the same effect is the right way). New countries don't appear all that often, so there has been very little need to be concerned about that. But once politicians discover that their country has been downgraded to appear as subservient to their neighbour, and that they can easily fix that by making a relative harmless alteration to their time rules, can't you imagine some of them being very tempted - and once one or two make it happen, successfully (remember, your objective seems to be mindless following of the written guidelines - which means a new zone whenever times differ after 1970, and you apparently want no room for discretion - that would invite politics) isn't it likely that lots of others would jump on the bandwagon. We're talking about politicians here remember, the kind of person who'd love to be designated as the Saviour of XXXland's timezone. kre
participants (18)
-
Almaz Mingaleev -
Christos Zoulas -
Clive D.W. Feather -
Derick Rethans -
Eliot Lear -
Florian Weimer -
Guy Harris -
Howard Hinnant -
Kevin Kenny -
Kim Davies -
Martin Burnicki -
Paul Eggert -
Peter Ilieve -
Peter Krefting -
Philip Paeps -
Robert Elz -
Steffen Nurpmeso -
Stephen Colebourne