- tz - lists.iana.org

(no subject)
by Cool Gab19 Sept. 30, 2021

Sept. 30, 2021

I knew that we do already have a time zone for Philippines, Asia/Manila called "Philippine Standard Time" with an offset of UTC+8:00 but the other one I was requesting is for the body of water surrounded inside the mainland such as the Ocean or Sea. I'm proposing to add UTC/GMT+8:15 to your database We do have an 8:30 and 8:45 zone. Why not 8:15? Plus,and if there's an specific location it's Asia/Philippines with different abbreviation "Philippine Pacific Time" with offset of UTC+8;15and will be used inside Philippine sea (not in mainland)

2 1

something wrong with 2021b zdump
by 大山俊成 Sept. 30, 2021

Sept. 30, 2021

I compared 2021b with 2021a. The result is following. I don't understand the meaning for line 3-5,20-22 of 2021b result. Is it correct ? *** tzdb-2021b $ ./zdump -v Pacific/Honolulu Pacific/Honolulu -9223372036854775808 = NULL Pacific/Honolulu -67768040609740801 = NULL Pacific/Honolulu Thu Jan 1 00:00:00 -2147481748 UT = NULL Pacific/Honolulu Thu Jan 1 10:31:25 -2147481748 UT = NULL Pacific/Honolulu Thu Jan 1 10:31:26 -2147481748 UT = Thu Jan 1 00:00:00 -2147481748 LMT isdst=0 gmtoff=-37886 Pacific/Honolulu Mon Jan 13 22:31:25 1896 UT = Mon Jan 13 11:59:59 1896 LMT isdst=0 gmtoff=-37886 Pacific/Honolulu Mon Jan 13 22:31:26 1896 UT = Mon Jan 13 12:01:26 1896 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Apr 30 12:29:59 1933 UT = Sun Apr 30 01:59:59 1933 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Apr 30 12:30:00 1933 UT = Sun Apr 30 03:00:00 1933 HDT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun May 21 21:29:59 1933 UT = Sun May 21 11:59:59 1933 HDT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun May 21 21:30:00 1933 UT = Sun May 21 11:00:00 1933 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Mon Feb 9 12:29:59 1942 UT = Mon Feb 9 01:59:59 1942 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Mon Feb 9 12:30:00 1942 UT = Mon Feb 9 03:00:00 1942 HWT isdst=1 gmtoff=-34200 Pacific/Honolulu Tue Aug 14 22:59:59 1945 UT = Tue Aug 14 13:29:59 1945 HWT isdst=1 gmtoff=-34200 Pacific/Honolulu Tue Aug 14 23:00:00 1945 UT = Tue Aug 14 13:30:00 1945 HPT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun Sep 30 11:29:59 1945 UT = Sun Sep 30 01:59:59 1945 HPT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun Sep 30 11:30:00 1945 UT = Sun Sep 30 01:00:00 1945 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Jun 8 12:29:59 1947 UT = Sun Jun 8 01:59:59 1947 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Jun 8 12:30:00 1947 UT = Sun Jun 8 02:30:00 1947 HST isdst=0 gmtoff=-36000 Pacific/Honolulu Wed Dec 31 23:59:59 2147485547 UT = Wed Dec 31 13:59:59 2147485547 HST isdst=0 gmtoff=-36000 Pacific/Honolulu 67768036191676800 = Wed Dec 31 14:00:00 2147485547 HST isdst=0 gmtoff=-36000 Pacific/Honolulu 67768036191712799 = Wed Dec 31 23:59:59 2147485547 HST isdst=0 gmtoff=-36000 Pacific/Honolulu 67768036191712800 = NULL Pacific/Honolulu 9223372036854775807 = NULL *** tzdb-2021a $ ./zdump -v Pacific/Honolulu Pacific/Honolulu -9223372036854775808 = NULL Pacific/Honolulu -9223372036854689408 = NULL Pacific/Honolulu Mon Jan 13 22:31:25 1896 UT = Mon Jan 13 11:59:59 1896 LMT isdst=0 gmtoff=-37886 Pacific/Honolulu Mon Jan 13 22:31:26 1896 UT = Mon Jan 13 12:01:26 1896 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Apr 30 12:29:59 1933 UT = Sun Apr 30 01:59:59 1933 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Apr 30 12:30:00 1933 UT = Sun Apr 30 03:00:00 1933 HDT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun May 21 21:29:59 1933 UT = Sun May 21 11:59:59 1933 HDT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun May 21 21:30:00 1933 UT = Sun May 21 11:00:00 1933 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Mon Feb 9 12:29:59 1942 UT = Mon Feb 9 01:59:59 1942 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Mon Feb 9 12:30:00 1942 UT = Mon Feb 9 03:00:00 1942 HWT isdst=1 gmtoff=-34200 Pacific/Honolulu Tue Aug 14 22:59:59 1945 UT = Tue Aug 14 13:29:59 1945 HWT isdst=1 gmtoff=-34200 Pacific/Honolulu Tue Aug 14 23:00:00 1945 UT = Tue Aug 14 13:30:00 1945 HPT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun Sep 30 11:29:59 1945 UT = Sun Sep 30 01:59:59 1945 HPT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun Sep 30 11:30:00 1945 UT = Sun Sep 30 01:00:00 1945 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Jun 8 12:29:59 1947 UT = Sun Jun 8 01:59:59 1947 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Jun 8 12:30:00 1947 UT = Sun Jun 8 02:30:00 1947 HST isdst=0 gmtoff=-36000 Pacific/Honolulu 9223372036854689407 = NULL Pacific/Honolulu 9223372036854775807 = NULL ---- Toshinari Ohyama

2 2

Merged 1970+ time zones should always return -1 pre-1970
by Brian Inglis Sept. 29, 2021

Sept. 29, 2021

I think for all zones with data merged prior to 1970, the data and API should always return *-1* for all times prior to 1970-01-01 00:00:00Z, as anything else is inaccurate or a kludge. Arbitrary disposition of any valid historical data is itself really political, for ease of administration, not really technical. I firmly believe that no decision on the list has ever been made on a basis of in-/equity or un-/fairness, as those would be political decisions, and we have bent over backwards for years to avoid any such appearance never mind actuality, devoting probably the majority of the volume of posts and the majority of the volume of words to such discussions. I have always taken the position that any churn not necessitated by changes on the ground (or government offices) is detrimental to the project and the database, and places a massive burden on downstreams who make good use of that data, including the CLDR and ICU projects, astronomy and astrology applications, all facets of the transportation industry, the databases they maintain, and the storage of what was the truth at a previous point in time, and future application uses of that previously stored data. Any such churn should be mediated by the request the list makes of time zone decision makers: to provide adequate notice of such changes, at least six months, preferably longer. I can only believe that the adminstrators of this database are under some form of political pressure (perhaps /only/ "vitriol in private email", which appears to be nearing the norm in certain arenas) to dispose of some data to achieve some misguided form of "equity" and "fairness", in response to some misguided perception of "inequity" and "unfairness" that is not apparent to members of this mailing list, and from the reactions, nor does it appear to have been adequately or clearly expressed in a form that members of this list can readily comprehend, nor is it clearly exactly when these political terms entered the discussion, nor what business they have being in it. As in any project where decisions are questionable, it is necessary to back off making any! The proposers of drastic changes need to enunciate clearly: * exactly what technical problem they perceive, and why it appears to be a problem; * some alternative options for technical solutions and/or approaches to address the technical problem; * how each alternative option for technical solutions and/or approaches to address the problem will satisfy the majority of needs of the majority of the stakeholders, and impacts on those unsatisfied; * why they think the option they propose to adopt is the best and most comprehensive solution to address the problem, and satisfies the most needs of the most stakeholders. This is standard practice in most commercial projects. It is often used when stakeholders can not quickly make a decision, decide on policy, or easily change policy. It allows development to proceed in parallel on all the offered options. When stakeholders finally decide or act, perhaps months along the timeframe nearing release, the selected option can be preferentially enabled, possibly with only minor tweaks or just data changes, and quickly regression tested to ensure the effect is precisely as desired. Of course, the best decision to satisfy the most needs of the most stakeholders is often the decision to just say "NO !" ;^> -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]

9 15

Using the tzdb: What's actually changed
by Watson Ladd Sept. 29, 2021

Sept. 29, 2021

Dear all, I see lots and lots of people who seem to be running applications that care about pre 1970 timestamps and don't use backzones, or seem to ignore links. Well, if you ignore links you deserve what you get: it's been documented that zones may become links. The size of tzdb has already caused problems for some embedded devices. Post-1970 correctness only strikes me as very reasonable. Applications that need more should use backzones, and this has been true for years. If you care about the truth of what time something happened, and it was recorded in local time, and the zone that it was in might need to get split in the future, and that split could change when the time was or other times you care about then the database isn't your problem, reality is. I see a lot of complaints, and very few details about the applications affected. Which makes me skeptical they actually exist. Remember, you're only affected if you deal with pre-1970 timestamps. Sincerely, Watson -- Astra mortemque praestare gradatim

4 5

[PATCH] Port better to >64-bit platforms
by Paul Eggert Sept. 29, 2021

Sept. 29, 2021

* zic.c (limitrange, writezone): Use max_time instead of ZIC_MAX when dealing with timestamps that would go into the TZif file. The distinction matters only on very unusual platforms where int_fast64_t is wider than 64 bits. --- zic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zic.c b/zic.c index c6feb8b..224cc22 100644 --- a/zic.c +++ b/zic.c @@ -1990,7 +1990,7 @@ limitrange(struct timerange r, bool locut, zic_t lo, zic_t hi, /* Omit ordinary and leap second transitions greater than HI + 1. */ - if (hi < ZIC_MAX) { + if (hi < max_time) { while (0 < r.count && hi + 1 < ats[r.base + r.count - 1]) r.count--; while (0 < r.leapcount && hi + 1 < trans[r.leapbase + r.leapcount - 1]) @@ -2205,7 +2205,7 @@ writezone(const char *const name, const char *const string, char version, error(_("too many transition times")); thistimelim = thistimei + thistimecnt; - if (thistimecnt && hi_time < ZIC_MAX + if (thistimecnt && hi_time < max_time && ats[thistimelim - 1] == hi_time + 1) hicut = false; memset(omittype, true, typecnt); -- 2.30.2

1 0

Request
by Cool Gab19 Sept. 29, 2021

Sept. 29, 2021

I'm proposing to add UTC/GMT+8:15? We do have an 8:30 and 8:45 zone. Why not 8:15? Plus,the GMT+8:15 if ever will be named as Anywhere on Southeast Asia Time (ASAT) (Asia/Southeast) a very usable time zone in southeast asian countries specially in zone 7 and 8.

2 1

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

Sept. 28, 2021

On 9/28/21 5:57 AM, crdrequest(a)ups.com wrote: > I was informed that the start Jordan now starts DST on February's last FRIDAY.....NOT THURSDAY. My guess is that you're OK because your informant referred to 00:00 on February's last Friday, which in 2022 is equivalent to what we have in tzdb 2021b (namely, 24:00 on February's last Thursday). The distinction between the two rules matters only in one year out of seven, the first such year being 2024 when February ends on a Thursday. Our source for the 24:00-on-last-Thursday rule is here (in Arabic): https://petra.gov.jo/Include/InnerPage.jsp?ID=189969&lang=ar&name=news

1 0

Why 2021b needed to be issued
by Paul Eggert Sept. 28, 2021

Sept. 28, 2021

Since 2013 I've been patching tzdb by replacing Zones with Links when Links suffice according to the guidelines. These patches have not affected timestamps after 1970. I've been doing this gradually. The changes have worked without significant incident, partly because end users generally don't care about pre-1970 timestamps, and partly because the few users who do care (astrologers, mostly) know or should know that the pre-1970 Zone data entries are often wrong and even when right are typically grossly inadequate for realistic use outside the named location - this is partly why any focus on pre-1970 is out of scope for tzdb. Preparing all these patches has been a big enough job that I've been doing it gradually since I have limited time. This process was discussed on the list before it began, and although there was some objection, a consensus to move towards these goals was reached at the time. Most of this job was done before 2021a came out. The main difference in this round of patches, is that I had aimed to complete the job, in response to a user query raising equity concerns in 2021a. It is clear that the 2021a setup was not sustainable in the long term, if equity is a goal. Completing the job generated larger patches than usual, and the patches' size triggered concern that they held too many changes all at once. Also, the patches' effects on pre-1970 timestamps in (for example) Norway and Sweden have triggered concerns, much more so than similar changes made (for example) to Angola and Congo in tzdb 2014g. My own view is that we've done this before, many times, it hasn't been a problem in practice, and it's way past time to address the equity concerns as they have a good chance to really bite this project and its repackagers in the future. It's a bad look for us that so much concern about Norway and Sweden has appeared on this mailing list, even though hardly anybody seems to have cared about Angola and Congo. It'll be an even worse look if we ignore this issue weeks, months or even years after it's been made clear to us. I wrote, tested and published several concrete suggestions addressing the fairness problem. In the months since May when the fairness problem was discovered and objections to my proposed fixes were raised, no other concrete fix addressing both of these concerns has been implemented or tested, and all other suggestions made so far would have required significant work, if they would have worked at all, or would have caused more data churn than what I proposed. I realize that there are valid concerns about installing too many of these patches at once, so 2021b affects only nine Zones instead of the thirty-odd Zones in my May proposal. The idea is to do further patch sets in not-too-distant-future releases, so that the job can finally be finished. I also recognize that there are other forms of equity and fairness that should be considered, perhaps along with alternative technical solutions to the problems these patches address. With all this in mind, issuing 2021b now is a significant step toward equity in tzdb. It will let us say that we are moving toward a fair process, and will give us the opportunity and motivation to improve on that process and to address and balance the various other concerns that have recently appeared on the mailing list.

3 3

Preparing to fork tzdb
by Stephen Colebourne Sept. 27, 2021

Sept. 27, 2021

Hi all, 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. It appears that there is soon to be a new release of tzdb containing these changes. In my opinion, the correct behaviour of the tzdb maintainer would be to revert the controversial changes before doing a release. In the event that the tzdb maintainer does not revert, consideration must be given to forking the project. The purpose of the fork would initially be to maintain the tzdb data set as it was prior to the dispute. This would then be released in parallel to the original tzdb to ensure that downstream projects do not each do their own thing (ie. to minimize incompatibilities downstream). Is there support for a fork? Is anyone willing to help out? Is any other group willing to sponsor tzdb (eg. CLDR or Red Hat)? Please reply to this thread with an indication of support and/or help. thanks Stephen Colebourne [1] https://mm.icann.org/pipermail/tz/2021-June/thread.html [2] https://mm.icann.org/pipermail/tz/2021-September/030372.html

31 151

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

Sept. 27, 2021

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

1 0

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

Sept. 27, 2021

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

1 0

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

Sept. 26, 2021

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

2 2

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

Sept. 26, 2021

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

28 40

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

Sept. 26, 2021

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

11 45

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

Sept. 26, 2021

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

1 0

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

Sept. 25, 2021

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

2 1

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

Sept. 25, 2021

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

17 30

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

Sept. 24, 2021

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

1 0

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

Sept. 24, 2021

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

1 0

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