- tz - lists.iana.org

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

2021b v 2021a1
by Michael Douglass Sept. 24, 2021

Sept. 24, 2021

I suspect the requests to have 2021b be 2021a+Samoa are reasonable - whatever view one has of Paul's changes and reasons. Internal processes of large organizations are not easily changed and modifying processes to accept 2021a1 will lead to all sorts of churn. I'd request: a: Paul move his changes to a branch and release 2021b as 2021a+Samoa b: Everybody take a break - at least for a (long) weekend c: Ratchet down the fury when we get back. Just my personal view,,,

8 7

DST in Jordan to start in February instead of March
by Steffen Thorsen Sept. 24, 2021

Sept. 24, 2021

The Jordanian Government announced yesterday that they will start DST in February instead of March: https://petra.gov.jo/Include/InnerPage.jsp?ID=37683&lang=en&name=en_news (English) "The Cabinet decided on Thursday to move the Kingdom's annual switch to summertime from the end of March to the end of February. The cabinet kept the switch to wintertime at the end of October. Clocks are to be set back by 60 minutes as of 1am of the last Friday of October every year, bringing the Kingdom two hours ahead of Greenwich Mean Time, while they will be set forward one hour on the last Thursday of February as of next year." https://petra.gov.jo/Include/InnerPage.jsp?ID=189969&lang=ar&name=news (Arabic) From the Arabic version, it seems to say it would be at midnight (assume 24:00) on the last Thursday in February, starting from 2022. There are a few news articles about it too: https://www.jordannews.jo/Section-109/News/Daylight-savings-now-starts-from… https://menafn.com/1102853678/Switch-to-summer-time-moved-a-month-earlier-t… Regarding the discussion on the future of backzone etc: My vote would also go for doing 2021a + just the necessary Samoa (+Jordan) patches in a 2021b until an agreement is made that is working well for everyone. We also depend on backzone data to be present somehow. Best regards, Steffen - timeanddate.com

2 1

Re: [tz] Preparing to fork tzdb
by Gerardo Ballabio Sept. 24, 2021

Sept. 24, 2021

Stephen Colebourne wrote: > On Thu, 23 Sept 2021 at 09:52, Paul Eggert via tz <tz at iana.org> wrote: > > On 9/22/21 2:53 AM, Almaz Mingaleev wrote: > > > What equity, diversity or inclusion issues were in 2021a? > > > > Locations in countries like Norway and Sweden got special treatment by > > being Zones, whereas locations in countries like Angola and Ethiopia > > were only Links. > > Taken at face value, it is easy for anyone reading this to nod their > head and agree that Norway should not receive favouritism over Angola. > > What it fails to state is that the solution adopted (creating Links > where previously there were Zones) has created a *different* equity, > diversity or inclusion issue. The resulting tzdb state clearly favours > Berlin over Oslo or Stockholm, Brussels over Amsterdam. Guys, PLEASE!!! That is ridiculous. Stop that madness. The distinction between Zones and Links is an internal implementation detail. It makes no practical difference [*]. Why should users care whether their location is a Zone or a Link? Why would they even need to know? If anybody actually complained about their favourite location not getting a "first-class treatment", I believe that "Get a life!" would be a fully deserved answer. [*] That changing an existing Zone to a Link might alter some data for that location is another issue that IMHO deserves consideration. Basically, it's a matter of deciding how much you commit to backward compatibility, and whether the impacted data are within the scope of that commitment. But that's completely orthogonal to the bogus "favouritism" issue. Gerardo

1 0

Issues with pre-1970 information in TZDB
by Stephen Colebourne Sept. 24, 2021

Sept. 24, 2021

(David Braverman recently asked for a summary of the issue. This is my attempt to summarize in a relatively even-handed way) The TZDB theory file starts with the following: "The tz database attempts to record the history and predicted future of civil time scales. It organizes time zone and daylight saving time data by partitioning the world into timezones whose clocks all agree about timestamps that occur after the POSIX Epoch (1970-01-01 00:00:00 UTC. Although 1970 is a somewhat-arbitrary cutoff, there are significant challenges to moving the cutoff earlier even by a decade or two, due to the wide variety of local practices before computer timekeeping became prevalent." I have always thought this is a wise choice for the management of time zone data. I suspect that most people on this list would agree. The rules for creating new IDs where post-1970 data differs are well understood and, I believe, agreed upon. Apart from debates over negative daylight saving, I do not believe there are any significant issues with the data post-1970. Despite the theory file introduction above, TZDB does in fact contain data for some locations before 1970. The issue at hand is which timezone IDs are allowed to have this data and which are not. And more broadly, the degree to which it is acceptable to change the status quo on the pre-1970 data. Over many years, pre-1970 data was added to many different IDs. However, over recent years, pre-1970 data has been removed. (Technically, it has been moved to another file, but for the purposes of those consuming the main set of tzdb files it has effectively been removed.) The net result of recent changes are various situations which might be described as "cleaner", "more equitable", "nonsensical", "unacceptable" or "less equitable" depending on your viewpoint. For example, Europe/Berlin has pre-1970 data, but Europe/Oslo and Europe/Stockholm do not. In technical terms, Europe/Oslo and Europe/Stockholm are now aliases for Europe/Berlin (known as Links in tzdb). Where the problem lies is that a user who queries Europe/Oslo for the timezone offset in 1950 used to get the data for Oslo but will now get the data for Berlin. Depending on your viewpoint this is "irrelevant", "unfortunate" or "offensive". Why has the data changed? Because Oslo, Stockholm and Berlin all have the same timezone data post-1970, and Berlin is the largest city. The argument is that if only post-1970 data matters (as per the theory file), then there is no justification for three separate data sets when only one will do, and the one chosen is the one with the largest city. The counter argument is that merging data sets across country boundaries is unacceptable and politically naive, particularly when there were no complaints about the previous status quo. More broadly, different individuals, some representing organizations, have expressed different opinions on what they do or do not want from the tzdb data set. Some would like a full historical record of time zone data, others want stability, many I suspect have absolutely no interest whatsoever in pre-1970 data. My personal concerns are data stability (agreed managed changes are OK), and the politically-sensitive inaccuracy that results from merging across country boundaries. Can we keep responses limited on this thread? Perhaps only respond if you think I've mischaracterized the issues at stake here? Or missed something obvious? Stephen

17 72

Re: [tz] proposal for new tzdb versions
by Shawn Steele Sept. 23, 2021

Sept. 23, 2021

+1, it would be best if the 2021b had the minimal fix required to support the immediate timezone changes needed and defer additional cleanup/refactoring until the group has reached more of a consensus on how to handle the various concerns raised. -Shawn (I'll also confess to not having had time to catch up on ALL of the email flying around about this, however the passionate discourse by itself would seem to be an indication that we should take a step back and pause, making only the minimal changes required immediately.) ------------------------------ Message: 3 Date: Wed, 22 Sep 2021 11:52:20 -0700 From: Mark Davis ?? <mark(a)macchiato.com> To: Tom Lane <tgl(a)sss.pgh.pa.us> Cc: Paul Eggert via tz <tz(a)iana.org> Subject: Re: [tz] proposal for new tzdb versions Message-ID: <CAJ2xs_E8TMP7bhsjnM4QCCTGKDd8SnqW3bh-Am0jab3yJq0x5g(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" I agree with Tom's comments. We *really* don't want the disruption that would happen when some people pick up the 2021b and others pick up 2021a1; especially when it is likely that many of the people picking up 2021b won't know that they could be breaking downstream clients. There is *no* harm at all to just issuing a 2021b that has 2021a + Somoan fix right now (no other changes). That is the simple option for now. Then people have the opportunity to hash out the situation without disruption. Mark

1 0

An alternate framing of timezone maintenance
by Russ Allbery Sept. 23, 2021

Sept. 23, 2021

Over the past few days, I've felt like the framing of the discussion hasn't taken into account Paul's clearly expressed desire for the part of maintenance he wants to focus on, and has not attempted to incorporate that into a design that would preserve other properties that other mailing list participants are interested in. I've also wondered if all parties are making unnecessarily strong assumptions about the nature of tz maintenance that exclude potentially useful designs. In the hope of applying the maxim that all problems in computer science can be solved by adding a level of indirection, here's a wild proposal that, even if not workable as-is, might help in looking at the discussion from a different angle. One can think of the tz database as two layers. The first is a collection of rulesets that represent rules for clock changes in particular regions. Call that the timekeeping data set. The second is a many-to-one assignment of names to those rulesets. Call that the naming layer. The scheme used for the naming layer attempted to avoid politicization of that layer by using the continent and largest city approach. This was largely successful, particularly by the standards of attempts of this sort, but not entirely so. For years now, the tz project has in essence asked people to treat the zone names as opaque identifiers and not imbue them with political meaning. Unfortunately, because those identifiers embed real-world names with other meanings in other contexts, I believe this effort is doomed to never fully succeed. The names and spellings of cities are political. The choice of continent to which to assign a city can be political. Population counts are political. Readers of the mailing list can fill in more examples. However, the timekeeping data set, divorced from the naming layer, is as close to apolitical as anything involving laws and human practice could be. Putting aside timezone abbreviations, nearly all of the political conflict is over the naming layer, not the timekeeping data set. I believe Paul has clearly indicated that the part of the work that he wants to focus on is maintenance of the timekeeping data set. I would characterize his recent proposed changes as attempts to make the naming layer less political to reduce political arguments and thus allow more time and attention to be spent on the timekeeping data set, which is where the primary value of the project lies. The stability concerns that have prompted most of the recent discussion are almost entirely about the naming layer. Suppose we resurrect the idea of opaque timezone identifiers. Specifically, suppose that we *add* a new, random identifier, something like TZ0045 with random digits, to all existing rulesets in either the main database or backzone. These identifiers would be unique identifiers for the dataset itself, independent of any other names. These identifiers would immediately have some useful properties: 1. Historic times for a given identifier would change only if we discovered that the previous times were clearly erroneous. Apart from fixing discovered errors, historic times would be stable for any given identifier. 2. Looking forward, new identifiers may be added if portions of an existing region diverge in their timekeeping practices or if someone gathers new historical information that would prompt the creation of a new backzone ruleset, but that's the only possible change. Identifiers will never change or be retired. 3. These identifiers carry absolutely no additional political content on top of the rules themselves. In other words, they add no new political problems not inherent and unavoidable in the data itself. Adding these identifiers would nearly double the number of names in the current tz database, which is unfortunate, but certainly far less disruptive than the sorts of changes that have recently been considered. Once these identifiers exist, the combination of those identifiers and the timekeeping data set form a nearly apolitical collection of data to which a naming layer can be cleanly applied. One can, for example, define a naming layer that exactly corresponds to the naming in use in the previous release of the tz database. With the exception of the implementation detail that the previous names become links to a new canonical identifier, the combination of that naming layer and that conception of the timekeeping data set is functionally identical to the previous tz release (except for the normal sorts of modifications for on-the-ground timekeeping changes). This may sound like a lot of work just to get back to where we already are, but with a pile of new, ugly names. But the point of such a change is that it now permits a separation of concerns and even potentially a separation of maintenance. The timekeeping data set is now a separate artifact that those whose primary interest is in timekeeping data can focus on without having to get involved in political naming discussions. It achieves the goal that Paul has been working towards (but which is impossible to fully achieve with the current naming) of separating the data from political and historical decisions about who got a timezone name and who didn't. And (very slowly, of course) there is now the possibility for consumers of the tz database to opt out of the naming conventions. One could, for instance, choose a timezone based on selection from a map and have that correspond to the unique, permanent timezone identifier. Meanwhile, clearly there is a strong interest in the naming layer and a strong desire to continue to maintain it along lines that Paul is not entirely comfortable with. Recently, that discussion has focused on naming stability, but other parties have expressed other interests in the past (adding new spellings of cities, ensuring a name exists for every ISO-recognized country, ensuring a name exists for regional capitals that are commonly referenced locally as the name for a timezone, etc.). Nothing is going to make those discussions go away, as the past many years of discussions here have shown, but now they are separable from the timekeeping data set and participants can decide which part of the maintenance they're interested in. If Paul (or any other contributor) wished, he could choose to focus on the part of the project that he finds the most interesting and leave maintenance of the naming layer largely to other parties. Given recent mailing list traffic, there is obviously substantial interest in that naming layer and thus I'm sure there will be no shortage of volunteers to help maintain it. And those who make decisions about the naming layer can then also absorb the consequences of those decisions, such as handling arguments over the spelling of cities. It would even be possible (although not necessary) to move discussion of the naming layer to a separate mailing list to more clearly separate political discussion from ruleset maintenance and technical work on the associated code libraries. The naming layer, which is now nearly devoid of technical decisions, could even be delegated to a more political body that deals with these sorts of conflicts constantly and is thus better equipped to handle them than the tz mailing list. Numerous options like that become possible. Even if a maintenance split doesn't happen, I think everyone may benefit from cleanly separating the spectacularly high-quality resource of rulesets and their accompanying exhaustive references, discussion, and human-readable descriptions of applicable regions from the politically fraught but technically quite small and simple naming layer. This idea may not be workable for reasons that aren't obvious to me at nearly 4:00am, but hopefully it will at least provide a different angle from which to look at the current arguments and possibly achieve some clarity about which portions of the overall tz project people are interested in working on and where the exact controversy lies. -- Russ Allbery (eagle(a)eyrie.org) <https://www.eyrie.org/~eagle/>

5 8

FW: Re: Preparing to fork tzdb
by dpatte Sept. 23, 2021

Sept. 23, 2021

I should add that no research scientist expects all historical data to be perfect before publishing. History always gets murkier the further you go back. All historical data is in fact best-guess, published so it can be improved upon We should be providing a forum for this.. See below..Sent from my Galaxy -------- Original message --------From: dpatte <dpatte(a)relativedata.com> Date: 2021-09-22 18:32 (GMT-05:00) To: Guy Harris <gharris(a)sonic.net> Cc: Watson Ladd <watson(a)cloudflare.com>, tz <tz(a)iana.org>, Eliot Lear <lear(a)lear.ch> Subject: Re: [tz] Preparing to fork tzdb I don't believe anyone has suggested that zones should be limited to 'only one zone per country'. I certainly never sugested that. In fact quite the opposite. But I believe there should be AT LEAST one zone per iso country, and it was the removal of the Montreal historical data a few years back that got me started.If it's THE tz database, it should be able to provide not only since-70 history, but be expandable to all tz history, potentially back to the 1800s when most cities implemented local mean time as local standards.I recognize many users of this db dont need pre1970 history, and perhaps they could filter for only recent data. But many apps need UT (gmt) before 1970 as I mentioned. Think astronomy apps, for example.Up until recently some of this data was available in the main tz file. We need that back, with the ability to expand and improve it. This should be possible without expanding the post1970 table.Sent from my Galaxy-------- Original message --------From: Guy Harris <gharris(a)sonic.net> Date: 2021-09-21 21:02 (GMT-05:00) To: dpatte <dpatte(a)relativedata.com> Cc: Watson Ladd <watson(a)cloudflare.com>, tz <tz(a)iana.org>, Eliot Lear <lear(a)lear.ch> Subject: Re: [tz] Preparing to fork tzdb On Sep 21, 2021, at 4:51 PM, dpatte via tz <tz(a)iana.org> wrote:> Date: 2021-09-21 18:49 (GMT-05:00)> To: dpatte <dpatte(a)relativedata.com>> Cc: Eliot Lear <lear(a)lear.ch>, "Clive D.W. Feather" <clive(a)davros.org>, tz <tz(a)iana.org>> Subject: Re: [tz] Preparing to fork tzdb> >> On Tue, Sep 21, 2021 at 3:42 PM dpatte <dpatte(a)relativedata.com> wrote:>> >>> The strategy used since tz was created has caused many political arguments and decisions in this group instead of deferring the decisions to the ISO that has this mandate.>> >> ISO countries doesn't solve some of the thorny political issues,>> because ISO codes don't take a position on boundary disputes or naming>> disputes. E.g. Crimea. When the invasion happened, the civil time in>> the region occupied changed. That means a new zone entry needed to be>> created. I don't know how defering to ISO resolves the naming of that>> one.>> >> The other example would be Palestine. Regardless of what ISO decides,>> the time in Palestine is what it is, and is different from Israel in>> funny ways, and the territories that have gone back and forth have>> gone back and forth and thus need new entries.> > Incorrect..> > Iso 3166> > Ramallah is recognized in the State of Palestine.And Hebron, presumably - it's the city used for West Bank Palestine.> Sevastopol is recognized as a city as being in Ukraine.But it's not a city used for a tzdb - Simferopol is.And Kyiv is also a city in Ukraine, but, as far as I know, it keeps different time from Simferopol, and the tzdb recognizes that.However, "deferring to ISO" doesn't mean "providing one *and only one* tzdb region per ISO country"; such a policy would not work very well for the three largest countries listed in the northamerica file, for example.If, indeed, Crimea and the rest of Ukraine do not, in practice, keep the same time, then, hopefully, "deferring to ISO" also wouldn't mean "giving Crimea the same offset and rules as the rest of Ukraine".

2 1

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

Sept. 23, 2021

The Montreal data was moved out because an error was discovered in the montreal data post 1970 which made it equivalent to Toronto. Great. The data was improved.But people still want a way of getting at the data for montreal pre 1970.Is the data editable within the backzone file?Sent from my Galaxy -------- Original message --------From: Guy Harris via tz <tz(a)iana.org> Date: 2021-09-22 19:53 (GMT-05:00) To: Time Zone Mailing List <tz(a)iana.org> Subject: Re: [tz] Preparing to fork tzdb On Sep 20, 2021, at 1:06 AM, Stephen Colebourne via tz <tz(a)iana.org> wrote:> As most of you probably know, there is a dispute about the tzdb> maintainer's recent changes to merge large numbers of time-zones> [1][2]. These have the effect of wiping out historic time-zone> information on many locations where the data has been in tzdb for many> years.The comment at the beginning of 2021a's backzone says:# From Paul Eggert (2014-10-31):# This file contains data outside the normal scope of the tz database,# in that its zones do not differ from normal tz zones after 1970.# Links in this file point to zones in this file, superseding links in# the file 'backward'.# Although zones in this file may be of some use for analyzing# pre-1970 timestamps, they are less reliable, cover only a tiny# sliver of the pre-1970 era, and cannot feasibly be improved to cover# most of the era. Because the zones are out of normal scope for the# database, less effort is put into maintaining this file. Many of# the zones were formerly in other source files, but were removed or# replaced by links as their data entries were questionable and/or they# differed from other zones only in pre-1970 timestamps.so it's not as if this is the first time that historic information has been moved to backzone, which, although not "wiping it out" in the sense of making it no longer exist in any form in the tzdb repository or releases, removes it from any collection of compiled tzdb files not build using backzone, and removes it from any data set that applications get by reading tzdb source files and not reading backzone.One example of data that's in backzone in 2021a is the data for America/Montreal, the comment for which in 2021a backzone is:# Canada## From Paul Eggert (2015-03-24):# Since 1970 most of Quebec has been like Toronto; see# America/Toronto. However, earlier versions of the tz database# mistakenly relied on data from Shanks & Pottenger saying that Quebec# differed from Ontario after 1970, and the following rules and zone# were created for most of Quebec from the incorrect Shanks &# Pottenger data. The post-1970 entries have been corrected, but the# pre-1970 entries are unchecked and probably have errors.#The example that's being cited as a problem with the merge is Europe/Oslo, the comment for which in 2021a europe is:# Norway# http://met.no/met/met_lex/q_u/sommertid.html (2004-01) agrees with Shanks &# Pottenger.So one difference here appears to be that the pre-1970 data for Europe/Oslo may be accurate while the pre-1970 data for America/Montreal may be inaccurate.Another difference is that Toronto and Montreal are in the same country, while Oslo and Berlin aren't.So: Were there any complaints when America/Montreal was turned into a link in 2015c (if the NEWS file is to be believed)? Is the concern that there's software, processes, etc. that depend on Europe/Oslo having the correct pre-1970 data, because that data appears to match what The Norwegian Meteorological Institute says, whereas there may be less software, processes, etc. that depend on America/Montreal having pre-1970 data because that data might be bogus?

3 2