- tz - lists.iana.org

Re: [tz] Preparing to fork tzdb
by dpatte Sept. 27, 2021

Sept. 27, 2021

Most people in the Americas who live outside 'america' would prefer it being 'Americas', 'North_America' or better yet, just the iso country names.Sent from my Galaxy -------- Original message --------From: Paul Eggert via tz <tz(a)iana.org> Date: 2021-09-26 20:44 (GMT-05:00) To: Brooks Harris <brooks(a)edlmax.com> Cc: Time zone mailing list <tz(a)iana.org> Subject: Re: [tz] Preparing to fork tzdb On 9/22/21 11:32 AM, Brooks Harris via tz wrote:> Olsen's original insight to use towns and cities to name time zones > turns out to be extraordinarily useful.As a historical note, the naming convention you're talking about is something I originated and contributed to tzdb in 1993. Although I began with more-complicated names like Pacific/Fiji/Suva and North_America/US/Los_Angeles, the country names (and the "North_") were more trouble than they were worth, so I removed them before sending patches for Arthur to install.One of my early emails about my idea concluded that "It looks like this will take some time." Which it has.https://mm.icann.org/pipermail/tz/1993-October/009233.html

1 0

Samoa awakes to time change confusion
by Paul Eggert Sept. 27, 2021

Sept. 27, 2021

The Samoa Observer's James Robertson reported today that much of Samoa woke up in confusion today as mobile phones, computers, and other cellular-enabled devices displayed the time as 10:00 when it was in fact 09:00. Many reportedly arrived at church early because their cell phones incorrectly sprang forward. An anonymous employee at Digicel said that Digicel hadn't been given enough notice. Vodafone Samoa apparently did not respond to media inquiry. The Observer's Marc Membrere reports tomorrow that the president of the Samoa Information Technology Association (S.I.T.A.) criticized the government for not consulting tech experts about the effect of changing DST rules with so little notice. ---- Robertson J. Nation awakes to time change confusion. Samoa Observer. 2021-09-26. https://www.samoaobserver.ws/category/samoa/92122 Membrere M. "Daylight savings change rushed: S.I.T.A." Samoa Observer. 2021-09-27. https://www.samoaobserver.ws/category/samoa/92126

1 0

Re: [tz] [tz-announce] 2021b release of tz code and data available
by Paul Eggert Sept. 26, 2021

Sept. 26, 2021

On 9/26/21 3:38 AM, Michael H Deckers wrote: > Link America/Port_of_Spain America/Virgin > in line 755 of backzone should be converted to > Link America/St_Thomas America/Virgin That would create a link-to-a-link (America/Virgin → America/St_Thomas → America/Puerto_Rico), which would cause "make check_links" to fail. This maintainer check was put in several years ago, when some downstream software misbehaved with a link-to-a-link in one of our releases. And I suspect that even zic is not robust in the presence of arbitrary links-to-links, though I haven't tested this. I do see the semantic issue behind the change you're proposing, as America/Virgin is an old alias for America/St_Thomas. If we wanted to add support for links-to-links, I suspect someone would have to code up and test changes to zic.c, and we would definitely need to give downstream users considerable time to adjust to the change. I'm not sure it's worth it merely to support this very minor issue.

2 2

Replacing the TZ Coordinator
by Stephen Colebourne Sept. 26, 2021

Sept. 26, 2021

The TZDB project is guided by RFC 6557. Section 4 allows the list to seek an alternate TZ coordinator where "The TZ Coordinator is not performing the function in accordance with community wishes". https://www.rfc-editor.org/rfc/rfc6557.html#section-4 The RFC instructs as follows: Members of the community should raise the issue on the TZ mailing list and attempt to reach consensus on a new candidate to fulfill the role of TZ Coordinator. If rough consensus cannot be reached easily, the Area Directors of the IETF Applications Area should attempt to guide the members of the community to rough consensus. The candidate that is agreed upon by the community through rough consensus shall be presented to the IESG for confirmation. If rough consensus cannot be reached, even with guidance from the Applications Area Directors, the IESG shall use whatever means it has at its disposal to choose a candidate who in its best judgment will be able to fulfill the role of TZ Coordinator. Is there consensus on the list that a change is required? Is there a candidate willing to take on the role of TZ Coordinator? Stephen

28 40

Some thoughts about the way forward
by Tom Lane Sept. 26, 2021

Sept. 26, 2021

A modest proposal, if I may. Let's take it as read that Paul is going to stick to his guns about the May reorganization --- he's certainly shown no willingness to do otherwise. (I do accept that there are valid reasons for that move, even if I differ as to their importance.) What do we need to do to mitigate the undesirable consequences of that reorganization? After chewing on this for awhile, it seems to me that the really fundamental undesirable consequence is going to be inconsistent received versions of tzdb. Currently, the usage of backzone seems to be quite negligible [1]. But I fear it is certain that some platforms will start using backzone, in order to placate users who are negatively affected by the May changes. That will mean that those platforms will start showing different results from platforms that don't do that, for all zones in backzone (both old and new). I rate this outcome as disastrous on multiple levels, not least being the damage to the credibility of the tzdb project itself. To avoid that, I already proposed [2] that we drop the links in "backward" that are overwritten by backzone. This would have the effect that a non-backzone build would not offer those zone names at all, instead of presenting them as having the data content of some other zone. This would eliminate the issue of different platforms presenting different results for the "same" zone. If we do that, it seems probable that instead of some platforms adopting backzone, nearly all will, because otherwise their users will moan about their favorite zone being gone. I therefore further suggest that we make use of backzone be the default. Anybody who wants a "lean and mean" build can leave it out --- but they'll be presenting a clean subset of the data seen in the default build, rather than data that is different and known to be less good in some cases. This approach suggests that we make some adjustments in how we think about things. I think we ought to rename backzone to "extended" or something like that. We'd view tzdb as offering a "base" set of zones that are considered in-scope per the rule about different-since-1970, plus an "extended" set of zones that are out-of-scope and are not maintained as carefully as the base. (This really is just applying different terminology to the existing understanding about how backzone is maintained.) The primary advantage of doing it this way, rather than the way we're handling backzone now, is that it's a lot clearer to end users what the status of the extended zones is, and we're not confusingly offering two different versions of those zones. Assuming we make these changes before shipping git tip in its present form, we could expect that users in zones affected by the May changes would see no actual change in their TZ data. There would be a loss of data stability for users in the zones that were moved to backzone previously. I'm not terribly thrilled about that, but it seems like the least amount of damage to the least amount of people, compared to any other likely outcome. We could hopefully placate those users by pointing out that (1) the new data, while likely not perfect, is almost certainly a net improvement over what was shipped before, and (2) this is effectively reverting these zones to their pre-2015 state. We'd thus be acknowledging that the original implementation of backzone was a mistake, and undoing it with the least amount of side-effects we can manage. I shall now retire and wait to be shot at ... regards, tom lane [1] https://mm.icann.org/pipermail/tz/2021-September/030572.html [2] https://mm.icann.org/pipermail/tz/2021-September/030632.html

11 45

Re: [tz] Why 2021b needed to be issued
by dpatte Sept. 26, 2021

Sept. 26, 2021

Agreed.Sent from my Galaxy -------- Original message --------From: Stephen Colebourne via tz <tz(a)iana.org> Date: 2021-09-25 12:40 (GMT-05:00) To: Time zone mailing list <tz(a)iana.org> Subject: Re: [tz] Why 2021b needed to be issued "On Sat, 25 Sept 2021 at 06:23, Paul Eggert via tz <tz(a)iana.org> wrote:> The main difference in this round of patches, is that I had aimed to> complete the job, in response to a user query raising equity concerns in> 2021a. It is clear that the 2021a setup was not sustainable in the long> term, if equity is a goal.Equity is not a formal goal of the project. It is not documented oragreed in the RFC nor in the theory file. Your opinion of what isequitable does not align with mine.> Completing the job generated larger patches than usual, and the patches'> size triggered concern that they held too many changes all at once.Having read hundreds of emails over the past few months, I don't think*anyone* expressed the concern of patch size or too many changes.> Also, the patches' effects on pre-1970 timestamps in (for example)> Norway and Sweden have triggered concerns, much more so than similar> changes made (for example) to Angola and Congo in tzdb 2014g.It may not be pleasant to accept, but I would strongly argue thatplaces like Norway, Denmark, Sweden and the Netherlands are much moresignificant to the world economy than Angola and Congo. You simplycannot judge the impact based on what has happened before. Inaddition, the pre-1970 data being removed now is much betterresearched than much of what has previously been removed.> I also recognize that there are other forms of equity and fairness that> should be considered, perhaps along with alternative technical solutions> to the problems these patches address.Thank you for the acknowledgement.In summary, I am livid with the high-handed approach you have takenwrt the release of 2021b. Despite near unanimity of the mailing listrequesting you to release 2021a+MinimalChanges, you progressed 9 outof the 30 link merges based on a rationale that you acknowledge is notuniversally accepted.I believe your actions are against the spirit of the RFC, if not theletter (as decided by the IESG), as you "SHOULD take into accountviews expressed on the mailing list".I will now take a break from this matter for a long weekend, as thelist has requested. Later next week I will try to start a positivediscussion as to what the next steps can be.Stephen

1 0

Atlantic/Jan_Mayen, Arctic/Longyearbyen and Europe/Berlin
by Chris Walton Sept. 25, 2021

Sept. 25, 2021

Paul, 1. For the record, I detest the practice of linking zones across different ISO-3166 regions. Forcing one country to be associated with another country is politically and culturally offensive. 2. In 2021b you have: Atlantic/Jan_Mayen linked to Europe/Berlin. Arctic/Longyearbyen linked to Europe/Oslo. This seems inconsistent to me. If you insist on keeping Atlantic/Jan_Mayen linked to Europe/Berlin, then I think that the Europe/Berlin entry in zone1970.tab should show "DE,SJ" instead of just "DE". -chris

2 1

proposal for new tzdb versions
by Paul Eggert Sept. 25, 2021

Sept. 25, 2021

In light of the previous discussions and the fact that we need a new release very soon, I propose the following: * We release 2021b pretty much as-is (with the usual release administrivia such as updating NEWS). * We also generate a separate 2021a1 version, which is like 2021a except with the Samoa change that is prompting 2021b. This version recognizes the concerns about the number of changes to pre-1970 timestamps in 2021b. I'll do this by publishing a patch to 2021a, along with a patched tarball, on my website at UCLA. Although this is effectively a fork in the short term, the idea is that it's a small fork with the intent that we'll work together to combine the two approaches in later releases, taking the abovementioned concerns into account. There is precedent for this approach, in that when there were compatibility problems with earlier releases, I generated alternate tarballs to support downstream users while they were adapting their database readers. Although the two cases are not the same, generating an alternate distribution also has the benefit of giving us time. Although I haven't had time to read all the discussions so far (and email is still rolling in), I will try to take these discussions into account when writing the NEWS entries for the two versions. After the versions are published and the dust has settled, I hope that we can incorporate some of the suggestions that have been made, as we will then have time to implement and test them. I don't want this followup discussion to take a looong time, though, as the goal is to combine the two approaches soon. Since Samoa's rules change in less than 72 hours I plan to generate these new versions soon.

17 30

Re: [tz] Some thoughts about the way forward
by Kerry Shetline Sept. 24, 2021

Sept. 24, 2021

I’ve written code myself that depends on regex patterns (4 digits followed by one or two letters) to match timezone version numbers, so I definitely would not want to see the version formatting change, at least not abruptly and without plenty of lead time before the first version numbers in any new or modified format appear. > Specifically, this is what is documented and this is what our software supports: > >> Since 1996, each version has been a four-digit year followed by lower-case letter (a through z, then za through zz, then zza through zzz, and so on) > > Deborah

1 0

Re: [tz] Preparing to fork tzdb
by Shawn Steele Sept. 24, 2021

Sept. 24, 2021

(I subscribe to digests - though as many of those have been sent recently, it doesn't feel like a digest 😁) It's one thing to have a zone that has "always" behaved this way, and another to have folks feel like it was "taken away" from them. The first may have begrudging acceptance, but the second is harder to come to terms with. I confess the identifiers always bug me a bit when I don't actually live in the place being identified, but that's closest to my time zone. -Shawn ------------------------------ Message: 2 Date: Fri, 24 Sep 2021 00:43:26 -0700 From: Paul Eggert <eggert(a)cs.ucla.edu> To: Stephen Colebourne <scolebourne(a)joda.org>, Time Zone Mailing List <tz(a)iana.org> Subject: Re: [tz] Preparing to fork tzdb Message-ID: <3c8e2714-752c-83f3-fafd-61fd796c7353(a)cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed On 9/23/21 6:07 AM, Stephen Colebourne via tz wrote: > the solution adopted (creating Links > where previously there were Zones) has created a *different* equity, > diversity or inclusion issue. That's not a new issue. We've dealt with it many times, by dealing with questions like "How come there's no Asia/Beijing Zone?" When the issue comes up we point to the guidelines, which are based on timekeeping rather than traditional political issues. Although we can't expect the guidelines to be familiar in advance to everyone who asks such questions, explaining the guidelines hasn't been much of a problem in practice.

1 0