- tz - lists.iana.org

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

Fwd: New Version Notification for draft-murchison-rfc8536bis-02.txt
by Ken Murchison Sept. 22, 2021

Sept. 22, 2021

FYI, as a distraction from the fork/replace discussions. I have attached the side-by-side diff of this draft and RFC8536. I apologize for the non-substantive diffs in the examples - the latest xml2rfc tool adds separators between rows. -------- Forwarded Message -------- Subject: New Version Notification for draft-murchison-rfc8536bis-02.txt Date: Sun, 19 Sep 2021 04:53:41 -0700 From: internet-drafts(a)ietf.org To: Arthur David Olson <arthurdavidolson(a)gmail.com>, Arthur Olson <arthurdavidolson(a)gmail.com>, Kenneth Murchison <murch(a)fastmailteam.com>, Paul Eggert <eggert(a)cs.ucla.edu> A new version of I-D, draft-murchison-rfc8536bis-02.txt has been successfully submitted by Kenneth Murchison and posted to the IETF repository. Name: draft-murchison-rfc8536bis Revision: 02 Title: The Time Zone Information Format (TZif) Document date: 2021-09-19 Group: Individual Submission Pages: 45 URL: https://www.ietf.org/archive/id/draft-murchison-rfc8536bis-02.txt Status: https://datatracker.ietf.org/doc/draft-murchison-rfc8536bis/ Html: https://www.ietf.org/archive/id/draft-murchison-rfc8536bis-02.html Htmlized: https://datatracker.ietf.org/doc/html/draft-murchison-rfc8536bis Diff: https://www.ietf.org/rfcdiff?url2=draft-murchison-rfc8536bis-02 Abstract: This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined. This document replaces and obsoletes RFC 8536. The IETF Secretariat

1 0

Response to informal TZ database appeal
by Murray S. Kucherawy Sept. 22, 2021

Sept. 22, 2021

Colleagues, I am an IETF Area Director currently appointed to the Applications and Real Time (ART) area. On June 21, 2021, the ART Area Directors (ADs) received a request from Mr. Stephen Colebourne for intervention regarding a change made to the time zone database. I apologize for the delay in this response. The management of the time zone database is new to me and I wanted to ensure I had done a proper review with as much context as I could discover. Despite what I've learned, I may get some terminology below wrong; apologies if so, and I'm happy to be corrected. I take this to have been an informal appeal under the second step of RFC 6557 Section 5, which prescribes a public discussion with the participation of the ART ADs. As this was our first contact about this matter, I did not interpret the second step as having been completed, and thus this was not an appeal under the third step, which is a formal appeal to the full IESG with prescriptive results. That step, or indeed action under Section 4, remains available to you. This is a shortened version of a much longer discussion document that I have forwarded to the IESG for its reference should further appeals be lodged. Note that since this is being taken under the informal second step, nothing I say here is prescriptive. For context, RFC 6557 (also known as BCP 175) is the only normative document in force. The "theory.html" document is relevant but not normative; it has recorded an evolving set of guiding principles for the time zone database for decades, and they are maintained in the same repository as the data now in dispute. That document has been visible, and subject to discussion and proposed revisions by the community. In summary, I do not believe there is relief to be found for the instant complaint in RFC 6557. There appear to be three points comprising the complaint. Taking them in turn and citing from the message Mr. Colbourne posted to the list on June 3: (a) I contend that to date, the TZ coordinator has not actively shown any serious willingness to accept that the proposed changes are unacceptable to a significant segment of tzdb users. As such, the coordinator has not taken into account the views of the mailing list. I disagree. The TZ mailing list archive is testimonial to the contrary: The TZ Coordinator has engaged in good faith in several subsequent threads on the topic after the change was made, and has proposed other workarounds to accomplish the original goal while attempting to address the objections raised. RFC 6557 says, “... but SHOULD take into account views expressed on the mailing list.” ("SHOULD" is defined in RFC 2119.) This compels the TZ Coordinator to follow the community’s consensus, unless she/he fully understands the implications of not doing so. It is evident to me that in this case, that understanding exists. Therefore it is within the TZ Coordinator’s discretion to proceed. (b) I also contend that the "cleanup" being proposed is not within the charter of the project. Point 1 refers to new zones, thus is not applicable. Point 2 refers to correcting historical inaccuracies, yet it is clear that the proposed change *adds* historical inaccuracies. Point 3 refers to changes, but only in terms that reflect what people in the relevant location would have considered the time zone to have been, yet clearly the proposed change does not do that. No part of the charter permits the coordinator to willfully harm the database, nor to merge timezone regions, nor to increase the number of historical inaccuracies. Again, I disagree. It is worth noting at this point that RFC 6557 is over ten years old. As I reviewed it I became convinced that it, for better or worse, was written in the context of believing that the primary thing that needed to be sustained by the database is accurate time zone calculations as of 1970; aesthetics and "geopolitical" matters were a secondary consideration (if they were considered important at all). While I am sympathetic to the notion that this change may be disruptive to software or other agents that consume only the basic time zone data rather than the alternative representations also available, or may aggravate consumers on a personal level, I do not believe RFC 6557 provides a basis for demanding the change be reverted given my observation above. (c) Justifications for the proposed change based on "consistency" or "politics" are not rooted in the charter of tzdb and should be considered null and void. I disagree. I found no evidence of "political" motivation. If "consistency" is not an acceptable justification, I find it curious that the theory document has not been challenged in the years since the relevant guidelines in it became stable. I have some recommendations for additional paths forward to consider, apart from further action under Sections 4 and 5 of RFC 6557: On the topic of consensus, the IETF published RFC 7282 some years ago, which describes its view of what “consensus” means in our context. It is not a governing document, but may be informative for future discussions or operation of the TZ mailing list. It is clear that in the years since RFC 6557 was published, consumers of this database have come to rely on it for particular local representations of time zones. Mr. Colebourne refers to this as an important “geopolitical” aspect of the database and asserts that the removal of the data implemented by this change will be disruptive to these consumers, so much so that he predicts this will necessitate a forking of the database, with that set of consumers following the fork. This is far from an ideal outcome, and naturally I strongly recommend that this not be how this matter is resolved by those dissatisfied with this (or any other) outcome. Experience has shown that a forked software or data project will always diverge, even with well-intentioned management of the fork to avoid such a delta from forming. Thus, such action could be enormously disruptive to the community. It is furthermore unlikely that the fork will enjoy the same level of oversight, meticulous curation of the data, resolution of disputes, vetting of proposed changes, etc., with any assured longevity. I therefore struggle to see how such action serves anyone in the long term. In any event, and perhaps most importantly, there is the matter of the tension between what the database was originally meant to be for and how people are now consuming it. This clearly cannot be ignored. I propose the community review both RFC 6557 and the “theory” document, giving careful consideration to the principles in each and their respective impacts, and also careful consideration to how the use of this database has evolved, and propose revising either or both to reflect current usage or desired management principles. The IETF has a procedure for revising its process documents (i.e., BCPs) from time to time when the community needs something different, and it would seem that may be the case here. I will be happy to initiate that process within the IETF if a critical mass exists to take up that work. Of note, there are points in the “theory” document that appear to lack supporting language. For example, “annoyingly large” appears to be a subjective criterion, not a technical one. That is, it is unclear what technical or process degradation, if any, is caused by these extra records, so the relevance of this point is not obvious, and therefore it is not clear why this is an important guideline to have in a technical specification. Also of note, I find the “consensus on the ground” requirement of RFC 6557 is probably in need of revision or, at a minimum, clarification. It is apparent that the intent there is to assure quality service to the local communities affected by change, but it includes no practical guidance as to how to do so. Finally, I believe your next formal steps under RFC 6557, should you wish to press the issue, will be one or both of the following: (a) A formal appeal under step 3 of Section 5, which should be addressed to iesg(a)ietf.org stating clearly that this is the formal appeal; or (b) An informal request for the assistance of the ART Area Directors to reach consensus on a candidate under Section 4, which can be addressed to art-ads(a)ietf.org or to me directly. -MSK, ART Area Director

3 3

Replacing the TZ Coordinator
by SM Sept. 22, 2021

Sept. 22, 2021

Hi Stephen, On Tue, Sep 21, 2021 at 10:42:47PM +0100, Stephen Colebourne via tz wrote: >Is there consensus on the list that a change is >required? >Is there a candidate willing to take on the role of TZ Coordinator? My reading of the debate is that a change is being requested because of a dispute about a decision to merge a large number of time zones. Section 5 of RFC 6557 provides a resolution path in case such a dispute arises. In my opinion, it would be premature to invoke Section 4. Regards, -sm

1 0

Undoing the effect of the new alike-since-1970 patch
by Paul Eggert Sept. 21, 2021

Sept. 21, 2021

There's been a clear need expressed to support tzdb users who would rather not deal with the effects of the recently-proposed alike-since-1970 patch. On the other hand there are also fairness and guideline-oriented reasons for the patch, which was originally discussed and installed with more than our usual care and review. Because of the extensive followup discussions I don't see how a single version could be appealing to both sides of this disagreement. So I propose we add a Makefile or similar build-time option to let tzdb users have it either way. Set the flag one way, and it will be as if the recently-proposed changes did not occur. Set it the other way, and you'll get the changes. This will be similar to our vanguard/rearguard support, which helped address a similar disagreement back in 2018. We could even control things via the existing vanguard/rearguard build-time option; that might be simpler. If you have ideas about what the the option's specific effects should be, please let me know. If there is support for this idea, I expect to be able to implement this option soon, in plenty of time before any urgent change due to a real-world rule change arrives. Like most compromises, I expect this approach to not be entirely satisfactory to anybody. However, I hope it helps us move forward together.

15 39

Pacific/Apia no DST from 25/Sep/2021
by Geoffrey D. Bennett Sept. 20, 2021

Sept. 20, 2021

Hi there, tzdata 2021a has Pacific/Apia starting DST 26/Sep/2021 at 3am: # zdump -v Pacific/Apia | grep 2021 Pacific/Apia Sat Apr 3 13:59:59 2021 UT = Sun Apr 4 03:59:59 2021 +14 isdst=1 gmtoff=50400 Pacific/Apia Sat Apr 3 14:00:00 2021 UT = Sun Apr 4 03:00:00 2021 +13 isdst=0 gmtoff=46800 Pacific/Apia Sat Sep 25 13:59:59 2021 UT = Sun Sep 26 02:59:59 2021 +13 isdst=0 gmtoff=46800 Pacific/Apia Sat Sep 25 14:00:00 2021 UT = Sun Sep 26 04:00:00 2021 +14 isdst=1 gmtoff=50400 But according to https://www.facebook.com/MCILSamoa/posts/1666781486865573 and https://www.mcil.gov.ws/storage/2021/09/MCIL-Scan_20210920_120553.pdf DST has been cancelled for this year. Thanks, Geoffrey.

2 1

[PROPOSED] Fix ambiguous leapsecs by rolling up to a minute
by Paul Eggert Sept. 18, 2021

Sept. 18, 2021

This fixes a longstanding ambiguity in the output of localtime in oddball timezones where a positive leap second occurs when the UTC offset is not a multiple of 60 seconds. See NEWS for details. * NEWS: Describe fix. * localtime.c (timesub): Use "??:??:60" at the end of the localtime minute containing the leap second, even when the second marked "??:??:60" is not itself a leap second. This avoids ambiguity in localtime output, at the cost of having the localtime leap second occur up to a minute away from the UTC leap second when the UTC offset is not a multiple of 60 seconds. * tzfile.5: Document the fixed and unfixed behaviors. --- NEWS | 18 ++++++++++++++++++ localtime.c | 22 +++++++++++++--------- tzfile.5 | 12 ++++++++++++ 3 files changed, 43 insertions(+), 9 deletions(-) diff --git a/NEWS b/NEWS index 1bf9cf3..6a77932 100644 --- a/NEWS +++ b/NEWS @@ -109,6 +109,24 @@ Unreleased, experimental changes transition in the table, or when handling far-future timestamps in slim TZif files lacking leap seconds. + Fix localtime misbehavior involving positive leap seconds in a + timezone with a UTC offset that is not on a minute boundary. + (No such timezone exists in tzdb, luckily.) Without the fix, + the timestamp was ambiguous during a positive leap second. + With the fix, the localtime leap second appears at the end of the + localtime minute containing the UTC second just before the UTC + leap second, which means leapseconds roll slightly in these + oddball timezones. Here is how the fix affects timestamps in a + timezone with UTC offset +01:23:45 and with a positive leap second + 78796801 (1972-06-30 23:59:60 UTC): + + time_t without the fix with the fix + 78796800 1972-07-01 01:23:45 1972-07-01 01:23:45 + 78796801 1972-07-01 01:23:45 1972-07-01 01:23:46 + ... + 78796815 1972-07-01 01:23:59 1972-07-01 01:23:60 + 78796816 1972-07-01 01:24:00 1972-07-01 01:24:00 + Fix an unlikely bug that caused 'localtime' etc. to misbehave if civil time changes a few seconds before time_t wraps around, when leap seconds are enabled. diff --git a/localtime.c b/localtime.c index 88fd35d..6a687d7 100644 --- a/localtime.c +++ b/localtime.c @@ -1681,20 +1681,23 @@ timesub(const time_t *timep, int_fast32_t offset, register time_t tdays; register const int * ip; register int_fast32_t corr; - register bool hit; register int i; int_fast32_t idays, rem, dayoff, dayrem; time_t y; + /* If less than SECSPERMIN, the number of seconds since the + most recent positive leap second; otherwise, do not add 1 + to localtime tm_sec because of leap seconds. */ + time_t secs_since_posleap = SECSPERMIN; + corr = 0; - hit = false; i = (sp == NULL) ? 0 : sp->leapcnt; while (--i >= 0) { lp = &sp->lsis[i]; if (*timep >= lp->ls_trans) { corr = lp->ls_corr; - hit = (*timep == lp->ls_trans - && (i == 0 ? 0 : lp[-1].ls_corr) < corr); + if ((i == 0 ? 0 : lp[-1].ls_corr) < corr) + secs_since_posleap = *timep - lp->ls_trans; break; } } @@ -1761,11 +1764,12 @@ timesub(const time_t *timep, int_fast32_t offset, tmp->tm_hour = rem / SECSPERHOUR; rem %= SECSPERHOUR; tmp->tm_min = rem / SECSPERMIN; - /* - ** A positive leap second requires a special - ** representation. This uses "... ??:59:60" et seq. - */ - tmp->tm_sec = rem % SECSPERMIN + hit; + tmp->tm_sec = rem % SECSPERMIN; + + /* Use "... ??:??:60" at the end of the localtime minute containing + the second just before the positive leap second. */ + tmp->tm_sec += secs_since_posleap <= tmp->tm_sec; + ip = mon_lengths[isleap(y)]; for (tmp->tm_mon = 0; idays >= ip[tmp->tm_mon]; ++(tmp->tm_mon)) idays -= ip[tmp->tm_mon]; diff --git a/tzfile.5 b/tzfile.5 index ec78689..4a88b75 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -279,6 +279,10 @@ the purpose of skipping over them. Readers should calculate the total lengths of the headers and data blocks and check that they all fit within the actual file size, as part of a validity check for the file. +.PP +When a positive leap second occurs, readers should append a 60th +second to the local minute containing the second just before the leap +second. .SS Common interoperability issues This section documents common problems in reading or writing TZif files. Most of these are problems in generating TZif files for use by @@ -398,6 +402,14 @@ thus swapping standard and daylight saving time. Although this workaround misidentifies which part of the year uses daylight saving time, it records UT offsets and time zone abbreviations correctly. +.IP * +Some readers generate ambiguous timestamps for positive leap seconds +that occur when the UTC offset is not a multiple of 60 seconds. +For example, in a timezone with UTC offset +01:23:45 and with +a positive leap second 78796801 (1972-06-30 23:59:60 UTC), they +map both 78796800 and 78796801 to 01:23:45 local time the next day +instead of mapping the latter to 01:23:46, and they map 78796815 to +01:23:59 instead of to 01:23:60. .PP Some interoperability problems are reader bugs that are listed here mostly as warnings to developers of readers. -- 2.31.1

4 11

[PROPOSED] Match RFC 8536bis-01 better
by Paul Eggert Sept. 18, 2021

Sept. 18, 2021

* NEWS: Mention this. * tzfile.5: The draft RFC 8536bis-01 came out today; match its wording better. --- NEWS | 5 +++++ tzfile.5 | 20 +++++++++++--------- 2 files changed, 16 insertions(+), 9 deletions(-) diff --git a/NEWS b/NEWS index 00dea3c..e5f5e90 100644 --- a/NEWS +++ b/NEWS @@ -182,6 +182,11 @@ Unreleased, experimental changes non-POSIX hosts where malloc doesn't set errno. (Problem reported by Jan Engelhardt.) + Changes to documentation + + tzfile.5 better matches a draft successor to RFC 8536 + <https://datatracker.ietf.org/doc/draft-murchison-rfc8536bis/01/>. + Release 2021a - 2021-01-24 10:54:57 -0800 diff --git a/tzfile.5 b/tzfile.5 index b1932bd..dd42660 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -152,13 +152,14 @@ Each pair denotes one leap second, either positive or negative, except that if the last pair has the same correction as the previous one, the last pair denotes the leap second table's expiration time. Each leap second is at the end of a UTC calendar month. -The first leap second is positive if and only if its correction is positive, -and the correction for each leap second after the first differs +The first leap second has a nonnegative occurrence time, +and is a positive leap second if and only if its correction is positive; +the correction for each leap second after the first differs from the previous leap second by either 1 for a positive leap second, or \-1 for a negative leap second. If the leap second table is empty, the leap-second correction is zero for all timestamps; -otherwise, for timestamps before the first correction time, +otherwise, for timestamps before the first occurrence time, the leap-second correction is zero if the first pair's correction is 1 or \-1, and is unspecified otherwise (which can happen only in files truncated at the start). @@ -255,11 +256,12 @@ any data that extends beyond the calculated end of the version .PP Other than version 1, writers should generate the lowest version number needed by a file's data. -For example, a writer should generate a version 3 file -if its leap second table neither expires nor is truncated at the start -and so does not use version 4 features, but +For example, a writer should generate a version 4 file +only if its leap second table either expires or is truncated at the start. +Likewise, a writer not generating a version 4 file +should generate a version 3 file only TZ string extensions are necessary to accurately -model transition times so the file does need version 3 features. +model transition times. .PP The sequence of time changes defined by the version 1 header and data block should be a contiguous sub-sequence @@ -433,9 +435,9 @@ abbreviations correctly. Some readers generate ambiguous timestamps for positive leap seconds that occur when the UTC offset is not a multiple of 60 seconds. For example, in a timezone with UTC offset +01:23:45 and with -a positive leap second 78796801 (1972-06-30 23:59:60 UTC), they +a positive leap second 78796801 (1972-06-30 23:59:60 UTC), some readers will map both 78796800 and 78796801 to 01:23:45 local time the next day -instead of mapping the latter to 01:23:46, and they map 78796815 to +instead of mapping the latter to 01:23:46, and they will map 78796815 to 01:23:59 instead of to 01:23:60. This has not yet been a practical problem, since no civil authority has observed such UTC offsets since leap seconds were -- 2.30.2

2 2

[PROPOSED] Improve leap second table truncation doc
by Paul Eggert Sept. 16, 2021

Sept. 16, 2021

* NEWS: Mention possible successor to RFC 8536, and relaxation on TZif reader’s restriction on gaps between leaps. * tzfile.5: Improve wording on leap second expiration. Specify correction before truncated leap second table more accurately, given how localtime.c behaves; for example, the first leap second is considered to be positive if and only if its correction is positive. Say what to do after leap second table expires. Add TZ="XXX3EDT4,0/0,J365/23" example. Say that positive leap seconds not at end of localtime minute have not been a practical problem yet. * tzfile.5, zic.8: Use \- (current font minus) instead of \(mi (math font minus). --- NEWS | 6 ++++- tzfile.5 | 77 ++++++++++++++++++++++++++++++++++++++------------------ zic.8 | 2 +- 3 files changed, 58 insertions(+), 27 deletions(-) diff --git a/NEWS b/NEWS index cc69995..00dea3c 100644 --- a/NEWS +++ b/NEWS @@ -86,7 +86,8 @@ Unreleased, experimental changes clients (including tzdb 2017c through 2021a) reject it, so "Expires" directives are currently disabled by default. To enable them, set the EXPIRES_LINE Makefile variable. If a TZif file uses - this new feature it is marked with a new TZif version number 4. + this new feature it is marked with a new TZif version number 4, + a format intended to be documented in a successor to RFC 8536. zic -L LEAPFILE -r @LO no longer generates an invalid TZif file that omits leap second information for the range LO..B when LO @@ -98,6 +99,9 @@ Unreleased, experimental changes correction other than -1 or +1, and to contain adjacent transitions with equal corrections. This supports TZif version 4. + The TZif reader now lets leap seconds occur less than 28 days + apart. This supports possible future TZif extensions. + Fix bug that caused 'localtime' etc. to crash when TZ was set to a all-year DST string like "EST5EDT4,0/0,J365/25" that does not conform to POSIX but does conform to Internet RFC 8536. diff --git a/tzfile.5 b/tzfile.5 index bab6390..b1932bd 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -142,16 +142,26 @@ pairs of four-byte values, written in network byte order; the first value of each pair gives the nonnegative time (as returned by .BR time (2)) -at which a leap second occurs; +at which a leap second occurs or at which the leap second table expires; the second is a signed integer specifying the correction, which is the .I total number of leap seconds to be applied during the time period starting at the given time. -The pairs of values are sorted in ascending order by time. -Each transition is for one leap second, either positive or negative; -transitions always separated by at least 28 days minus 1 second. -The first entry's correction is +1 (or \(mi1, for a hypothetical leap -second table where the first leap second was negative). +The pairs of values are sorted in strictly ascending order by time. +Each pair denotes one leap second, either positive or negative, +except that if the last pair has the same correction as the previous one, +the last pair denotes the leap second table's expiration time. +Each leap second is at the end of a UTC calendar month. +The first leap second is positive if and only if its correction is positive, +and the correction for each leap second after the first differs +from the previous leap second by either 1 for a positive leap second, +or \-1 for a negative leap second. +If the leap second table is empty, the leap-second correction is zero +for all timestamps; +otherwise, for timestamps before the first correction time, +the leap-second correction is zero if the first pair's correction is 1 or \-1, +and is unspecified otherwise (which can happen only in files +truncated at the start). .IP * .B tzh_ttisstdcnt standard/wall indicators, each stored as a one-byte boolean; @@ -201,7 +211,7 @@ POSIX-TZ-environment-variable-style string for use in handling instants after the last transition time stored in the file or for all instants if the file has no transitions. The POSIX-style TZ string is empty (i.e., nothing between the newlines) -if there is no POSIX representation for such instants. +if there is no POSIX-style representation for such instants. If nonempty, the POSIX-style TZ string must agree with the local time type after the last transition time if present in the eight-byte data; for example, given the string @@ -225,8 +235,8 @@ January 1 at 00:00 and ends December 31 at 24:00 plus the difference between daylight saving and standard time. .SS Version 4 format For version-4-format TZif files, -the first leap second transition can have a correction that is neither -+1 nor \(mi1, to support TZif files with reduced timestamp range. +the first leap second record can have a correction that is neither ++1 nor \-1, to represent truncation of the TZif file at the start. Also, if two or more leap second transitions are present and the last entry's correction equals the previous one, the last entry denotes the expiration of the leap second table instead of a leap second; @@ -237,32 +247,37 @@ the added leap seconds will change how post-expiration timestamps are treated. Future changes to the format may append more data. .PP Version 1 files are considered a legacy format and -should be avoided, as they do not support transition +should not be generated, as they do not support transition times after the year 2038. -Readers that only understand Version 1 must ignore +Readers that understand only Version 1 must ignore any data that extends beyond the calculated end of the version 1 data block. .PP Other than version 1, writers should generate the lowest version number needed by a file's data. For example, a writer should generate a version 3 file -if the file does not contain a truncated leap second table +if its leap second table neither expires nor is truncated at the start and so does not use version 4 features, but TZ string extensions are necessary to accurately model transition times so the file does need version 3 features. .PP The sequence of time changes defined by the version 1 -header and data block should be a contiguous subsequence +header and data block should be a contiguous sub-sequence of the time changes defined by the version 2+ header and data block, and by the footer. This guideline helps obsolescent version 1 readers agree with current readers about timestamps within the -contiguous subsequence. It also lets writers not +contiguous sub-sequence. It also lets writers not supporting obsolescent readers use a .B tzh_timecnt of zero in the version 1 data block to save space. .PP +When a TZif file contains a leap second table expiration +time, TZif readers should either refuse to process +post-expiration timestamps, or process them as if the expiration +time did not exist (possibly with an error indication). +.PP Time zone designations should consist of at least three (3) and no more than six (6) ASCII characters from the set of alphanumerics, @@ -272,7 +287,7 @@ and This is for compatibility with POSIX requirements for time zone abbreviations. .PP -When reading a version 2+ file, readers +When reading a version 2 or higher file, readers should ignore the version 1 header and data block except for the purpose of skipping over them. .PP @@ -306,7 +321,7 @@ design goal has been that a reader can successfully use a TZif file even if the file is of a later TZif version than what the reader was designed for. When complete compatibility was not achieved, an attempt was -made to limit glitches to rarely-used timestamps, and to allow +made to limit glitches to rarely used timestamps and allow simple partial workarounds in writers designed to generate new-version data useful even for older-version readers. This section attempts to document these compatibility issues and @@ -323,24 +338,33 @@ version 2+ data even if the reader's native timestamps have only 32 bits. .IP * Some readers designed for version 2 might mishandle -timestamps after a version 3 file's last transition, because +timestamps after a version 3 or higher file's last transition, because they cannot parse extensions to POSIX in the TZ-like string. As a partial workaround, a writer can output more transitions than necessary, so that only far-future timestamps are mishandled by version 2 readers. .IP * Some readers designed for version 2 do not support -permanent daylight saving time, e.g., a TZ string +permanent daylight saving time with transitions after 24:00 +\(en e.g., a TZ string .q "EST5EDT,0/0,J365/25" -denoting permanent Eastern Daylight Time (\-04). -As a partial workaround, a writer can substitute standard time -for the next time zone east, e.g., +denoting permanent Eastern Daylight Time +(\-04). +As a workaround, a writer can substitute standard time +for two time zones east, e.g., +.q "XXX3EDT4,0/0,J365/23" +for a time zone with a never-used standard time (XXX, \-03) +and negative daylight saving time (EDT, \-04) all year. +Alternatively, +as a partial workaround a writer can substitute standard time +for the next time zone east \(en e.g., .q "AST4" -for permanent Atlantic Standard Time (\-04). +for permanent +Atlantic Standard Time (\-04). .IP * -Some readers designed for earlier versions reject version 4 files, -because they require complete leap second tables that do not record -expiration dates. +Some readers designed for version 2 or 3, and that require strict +conformance to RFC 8536, reject version 4 files whose leap second +tables are truncated at the start or that end in expiration times. .IP * Some readers ignore the footer, and instead predict future timestamps from the time type of the last transition. @@ -413,6 +437,9 @@ a positive leap second 78796801 (1972-06-30 23:59:60 UTC), they map both 78796800 and 78796801 to 01:23:45 local time the next day instead of mapping the latter to 01:23:46, and they map 78796815 to 01:23:59 instead of to 01:23:60. +This has not yet been a practical problem, since no civil authority +has observed such UTC offsets since leap seconds were +introduced in 1972. .PP Some interoperability problems are reader bugs that are listed here mostly as warnings to developers of readers. diff --git a/zic.8 b/zic.8 index 3149440..ea7bab9 100644 --- a/zic.8 +++ b/zic.8 @@ -550,7 +550,7 @@ using the shortest form that does not lose information, where .IR mm , and .I ss -are the hours, minutes, and seconds east (+) or west (\(mi) of UT. +are the hours, minutes, and seconds east (+) or west (\-) of UT. Alternatively, a slash (/) separates standard and daylight abbreviations. -- 2.30.2

1 0

[CfP][CalendarFest] Call for lightning talk proposals for CalendarFest 2021 - current topics in electronic calendaring
by Hans-Joerg Happel Sept. 15, 2021

Sept. 15, 2021

Hi, my apologies for being slightly off topic, but I guess this might be interesting to see some of you / related to some topics discussed on this list. Please feel also free to forward this to anybody you might have in mind, who is dealing with novel calendaring solutions and ideas and might be interested in community discussion. Thanks and best, Hans-Joerg ----- CalendarFest is a novel (virtual) event, which wants to let users and developers of (electronic) calendar applications, servers, and related groupware systems, share experiences and discuss novel ideas. CalendarFest will take place *18th of October*, 02:30h PM UTC virtually via Zoom, and is held in conjunction with the CalConnect virtual conference <https://www.calconnect.org/events/calconnect-virtual-conference-autumn-2021>. Lightning talks People who wish to discuss or present certain topics are invited to submit a *proposal for lightning talks*. Lightning Talk presentations will be a maximum of 15-20 minutes each. Presenters may use slides, but these must be submitted to the Lightning Talks chair a few days before the presentation. Proposals Lightning Talk proposals must be submitted in PDF format. The proposal is limited to 1 page, 500 words max. The full proposal contains a title, an abstract (maximum 250 words) and a description where you should explain your talk in more detail. It will be helpful for reviewers to know why you are excited about the topic, and why you think others will be interested too. Outline how you plan to present your topic. The proposal also may contain a link to a website with more information. Possible Topics * Enterprise calendaring * Public calendaring * Calendaring and Semantic Web/Linked Data * Calendar Interoperability and Migration * Calendaring Security and Privacy by Design * Personal information management (PIM) and groupware * AI in calendaring * Calendaring and scheduling in IoT * Mobile calendaring * Calendar visualization, user experience and usability * Novel applications of calendars * Calendaring standards (vCard, iCal, CalDAV, CardDAV, JMAP) * Date/Time representations and Time zones * Business models for calendaring and groupware Program committee Submissions will be reviewed by the following members of the CalConnect TC-CLIENT technical committee: * Mike Douglass * Hans-Jörg Happel * Alex Nimmervoll Timeline * Send your lightning talk proposal to *calendarfest(a)calconnect.org <mailto:calendarfest@calconnect.org>* until *October, 4th* * You will receive a notification of acceptance or reject by October, 11th * CalendarFest will take place on October, 18th Participation Participation at CalendarFest will be free for presenters of accepted talks. Other participants need to register <https://www.calconnect.org/news/2021/09/02/registration-open-october-2021-c…> for a small organizational fee, which also allows for participation at the “colocated” CalConnect Virtual Conference. About CalConnect (www.calconnect.org <http://www.calconnect.org>) is a non-profit partnership between vendors and users of collaboration systems and tools, in particular calendaring and scheduling. CalConnect members convene regularly to discuss and develop standards for electronic calendaring and related topics. The goal of CalendarFest, which is held in conjunction with the CalConnect Virtual Conference, is to provide an interdisciplinary discussion space for current topics in electronic calendaring from different perspectives. *CalendarFest website: https://public.calconnect.org/CalendarFest/*

1 0

[PROPOSED] Don't mistruncate TZif files at leap seconds
by Paul Eggert Sept. 14, 2021

Sept. 14, 2021

Without this fix, zic mishandles the command ‘zic -L leapseconds -r @1706745601 etcetera’ when ‘leapseconds’ is generated from the test data file mentioned in: https://mm.icann.org/pipermail/tz/2021-September/030385.html The resulting, incorrect TZif file causes ‘TZ=Etc/GMT date -r 1706745601’ to output "Thu Feb 1 00:00:01 GMT 2024" instead of the correct "Thu Feb 1 00:00:00 GMT 2024", because localtime misinterprets the leap second entry at 1706745601 to be a positive instead of a negative leap second. * NEWS: Mention the fix. * zic.c (limitrange): When omitting leading leap seconds, do not output a leap second table that starts with a positive leap second with a nonpositive correction (or with a negative leap second with a positive correction) as that will confuse TZif readers into thinking the positive leap second is negative or vice versa. Instead, keep otherwise-unnecessary leading leap seconds to avoid the confusion. --- NEWS | 6 ++++++ zic.c | 14 ++++++++++++-- 2 files changed, 18 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 62a7ba2..9983f11 100644 --- a/NEWS +++ b/NEWS @@ -137,6 +137,12 @@ Unreleased, experimental changes last time transition disagreed with the TZ string, contrary to Internet RFC 8563 section 3.3. + Fix a bug with 'zic -r @X' when X is a negative leap second that + has a nonnegative correction. Without the fix, the output file + was truncated so that X appeared to be a positive leap second. + Fix a similar, even-less-likely bug when truncating at a positive + leap second that has a nonpositive correction. + zic -r now reports an error if given rolling leap seconds, as this usage has never generally worked and is evidently unused. diff --git a/zic.c b/zic.c index b06ef66..c6feb8b 100644 --- a/zic.c +++ b/zic.c @@ -1972,12 +1972,22 @@ limitrange(struct timerange r, bool locut, zic_t lo, zic_t hi, r.base++; } - /* Omit as many leap seconds < LO as possible, such that the first - leap second in the truncated list is <= LO. */ + /* Omit as many initial leap seconds as possible, such that the + first leap second in the truncated list is <= LO, and is a + positive leap second if and only if it has a positive correction. + This supports common TZif readers that assume that the first leap + second is positive if and only if its correction is positive. */ while (1 < r.leapcount && trans[r.leapbase + 1] <= lo) { r.leapcount--; r.leapbase++; } + while (0 < r.leapbase + && ((corr[r.leapbase - 1] < corr[r.leapbase]) + != (0 < corr[r.leapbase]))) { + r.leapcount++; + r.leapbase--; + } + /* Omit ordinary and leap second transitions greater than HI + 1. */ if (hi < ZIC_MAX) { -- 2.30.2

1 0

Re: [tz] No leap second on 2021-12-31
by Kerry Shetline Sept. 14, 2021

Sept. 14, 2021

What’s interesting is that the Earth is undergoing an odd span of time during which it has been spinning a bit faster instead of slowing down. If this keeps up, not only will it be a while until we see another leap second, but in a few years we might experience the first negative leap second, where a second is dropped from the end of the last minute just before 00:00 UTC. > Per IERS, Bulletin C 62 (2021-07-05) > https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.62 > > ?and forwarded below. > > A patch updating leap-seconds.list from NIST is attached, and is installed > in the development repository. > > -- > Tim Parenti

3 2

Further fix for Niue
by Tim Parenti Sept. 14, 2021

Sept. 14, 2021

While working on the recent changes to historical timestamps for Sierra Leone, the unique -11:20 offset for Niue caught my eye in contemporaneous editions of The Air Almanac which P Chan had sourced: specifically, that it was no longer there by the late 1960s. FInding a few more editions, I eventually found -11:20 listed for Niue as of Apr 1964 but -11 as of Aug 1964: Apr 1964: https://books.google.com/books?id=_1So677Y5vUC&pg=SL1-PA23 Aug 1964: https://books.google.com/books?id=MbJloqd-zyUC&pg=SL1-PA23 This points to a likely transition sometime around July 1964. 1978 did seem awfully late for such a unique offset. Proposed patch attached, and installed in the development repository. -- Tim Parenti On Wed, 24 Mar 2021 at 15:28, Paul Eggert via tz <tz(a)iana.org> wrote: > Thanks for the additional info about Cook and Niue. Proposed further > patch attached, and installed into the development repository. >

1 0

Historical fix for Tonga
by Tim Parenti Sept. 14, 2021

Sept. 14, 2021

First, a quick clerical patch: 0001, attached, fixes the placement of a comment which got shuffled around in the lead-up to publishing the changes for South Sudan in 2021a. Patch 0003 relates to Tonga, and comes from some of the links P Chan shared to 1957–1963 editions of The Air Almanac: https://mm.icann.org/pipermail/tz/2021-February/029866.html On Thu, 25 Feb 2021 at 03:43, P Chan <legco(a)outlook.com> wrote: > 1960 Nov (1962.1-4) > https://books.google.com/books?id=bVgtWM6kPZUC&pg=SL1-PA20 > 1961 Mar (1962.5-8) > https://books.google.com/books?id=W2nItAul4g0C&pg=SL1-PA20 When looking around at how this data was presented for other regions, I noticed on the preceding pages (listing "Places Fast on GMT", i.e., east of Greenwich) in some of the earlier editions provided that Tonga was listed at GMT+12:20. The peculiar offset stuck out, and I quickly noticed that some of the later editions of the same tables had it at GMT+13. A quick bisection puts the changeover, as far as The Air Almanac contemporaneously reckoned it, between November 1960 and March 1961. Previously, our data had Tonga transitioning to UT+13 in 1941 based on a quotation from a 1997 news article. Although this differs from what the Almanac suggests by some 20 years, the article does mention a change coincident with the New Year, and that Tāufaʻāhau Tupou IV was Crown Prince at the time. As his predecessor and mother, Queen Sālote Tupou III, reigned from 1918-04-05 to 1965-12-16, a possible transition of 1961-01-01 still jives with the gist of the article, even if the specific year was perhaps wrong or just misprinted. For what it's worth, our commentary already noted that Shanks & Pottenger had put the transition even later, at 1968-10-01. Although of course we don't know how they arrived at that date, given that they did, 1961 seems rather less out-of-place than it otherwise might. The attached patch 0003 makes this adjustment, while more fully documenting and comparing the conflicting sources. Thanks again to P Chan for pointing us to these resources. I wasn't expecting to get a "bonus" correction out of it, but one never knows quite what will catch the eye… -- Tim Parenti

3 3

[PATCH 1/8] * tzfile.5: Fix prefix/suffix typo (thanks to Ian Abbott).
by Paul Eggert Sept. 14, 2021

Sept. 14, 2021

--- tzfile.5 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tzfile.5 b/tzfile.5 index b4952d5..ec78689 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -134,7 +134,7 @@ bytes that represent time zone designations, which are null-terminated byte strings, each indexed by the .B tt_desigidx values mentioned above. -The byte strings can overlap if one is a prefix of the other. +The byte strings can overlap if one is a suffix of the other. The encoding of these strings is not specified. .IP * .B tzh_leapcnt -- 2.27.0

2 8

[PROPOSED] zic -r is incompatible with rolling leaps
by Paul Eggert Sept. 13, 2021

Sept. 13, 2021

* NEWS, zic.8: Mention this. * zic.c (leapadd): Report an error if the user tries it. --- NEWS | 3 +++ zic.8 | 3 +++ zic.c | 4 ++++ 3 files changed, 10 insertions(+) diff --git a/NEWS b/NEWS index 1b5535a..62a7ba2 100644 --- a/NEWS +++ b/NEWS @@ -137,6 +137,9 @@ Unreleased, experimental changes last time transition disagreed with the TZ string, contrary to Internet RFC 8563 section 3.3. + zic -r now reports an error if given rolling leap seconds, as this + usage has never generally worked and is evidently unused. + zic now generates a POSIX-conforming TZ string for TZif files where all-year DST is predicted for the indefinite future. For example, for all-year Eastern Daylight Time, zic now generates diff --git a/zic.8 b/zic.8 index b77841b..3023ebe 100644 --- a/zic.8 +++ b/zic.8 @@ -709,6 +709,9 @@ or .q "Rolling" if the leap second time given by the other fields should be interpreted as local (wall clock) time. +(Rolling leap seconds are not supported if the +.B \*-r +option is used.) .PP The expiration line, if present, has the form: .nf diff --git a/zic.c b/zic.c index e2a7e13..b06ef66 100644 --- a/zic.c +++ b/zic.c @@ -3144,6 +3144,10 @@ leapadd(zic_t t, int correction, int rolling) error(_("too many leap seconds")); exit(EXIT_FAILURE); } + if (rolling && (lo_time != min_time || hi_time != max_time)) { + error(_("Rolling leap seconds not supported with -r")); + exit(EXIT_FAILURE); + } for (i = 0; i < leapcnt; ++i) if (t <= trans[i]) break; -- 2.30.2

4 7

Re: [tz] [PROPOSED] Fix ambiguous leapsecs by rolling up to a minute
by Paul Eggert Sept. 13, 2021

Sept. 13, 2021

On 9/13/21 2:45 AM, Robert Elz wrote: > do the changes in this proposal also correctly handle negative > leap seconds that are (for whatever bizarre reason) shoved into the middle > of a minute? Good question. I don't know of any problems in that area, though, as the proposed change does not affect negative leap seconds. The problem with 2021a and earlier is that localtime labels are ambiguous in a positive leap second inserted into the middle of a localtime minute; for example, if a leap second is inserted between seconds 11 and 12 the count is ... 9, 10, 11, 11, 12, 13,... which is problematic. With a negative leap second, the clock skips a second so there can be no ambiguity and there is no need for a fix. If the 11th second is skipped, for example, the localtime seconds is simply ... 9, 10, 12, 13,.... This has long been the case in the code, and the proposed change does not affect this.

1 0