- tz - lists.iana.org

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