- tz - lists.iana.org

[YBA] TLD make using mawk causes malloc failure
by Jonathan Ben Avraham Jan. 19, 2022

Jan. 19, 2022

Dear colleagues, I noticed that on all tz versions up to 2021e running make in the top-level directory results in a malloc failure on Debian 10 which uses the mawk alternate for awk: cc -DTZDIR='"/usr/share/zoneinfo"' -c -o difftime.o difftime.c rm -f libtz.a ar -rc libtz.a localtime.o asctime.o difftime.o strftime.o : libtz.a awk -v DATAFORM=`expr main.zi : '$.*$.zi'` -f ziguard.awk \ africa antarctica asia australasia europe northamerica southamerica etcetera factory backward >main.zi.out malloc(): unsorted double linked list corrupted Aborted make: *** [Makefile:612: main.zi] Error 134 This can be corrected by installing gawk and running update-alternatives --config awk to select gawk as the awk alternate. I verified that the make completes without error using either GNU Awk 4.1.4, or GNU Awk 4.2.1. I did not see any warning about this in any of the NEW or README files, which is unfortunate as I spent several hours of my employers time understanding the problem and I suspect that others have seen this already. I suggest adding an INSTALL readme to say which environments are known to work and if there are specific know issues such as mawk. Best regards, - yba -- 9590 8E58 D30D 1660 C349 673D B205 4FC4 B8F5 B7F9 ~. .~ Tk Open Systems =}-------- Jonathan Ben-Avraham ("yba") ----------ooO--U--Ooo------------{= mailto:yba@tkos.co.il tel:+972.52.486.3386 http://tkos.co.il skype:benavrhm

3 3

Re: [tz] The State of Palestine has adopted the first part of the specification for its time zone
by Doug Ewell Jan. 15, 2022

Jan. 15, 2022

heba.hamad at mtit.gov.ps wrote: > We would like to inform you that The State of Palestine has adopted > the first part of the specification for its time zone. and linked a document which states in part: > Names normally have the form AREA/LOCATION, where AREA is a continent > or ocean, and LOCATION is a specific location within the area. > > The State of Palestine is the Palestine Time Zone owner, It has the > sole right to set, modify and register the Standard Time Zone; Name / > Database / DST. The Time Zone Database includes two zones related to Palestine, with the identifiers "Asia/Gaza" and "Asia/Hebron". These zones differ for (recent) historical reasons, because the rules for summer time (daylight saving time) varied during the period from 2008 to 2012. The file "asia" in the TZDB has comments which explain the exceptions for Gaza. By stating: > Palestine will use Palestine Standard Time (PSST), and Palestine > daylight time (PSDT). the PSI document appears to signal that the entire State of Palestine will observe a single changeover date and time, and will no longer observe different changeover dates in Gaza. However, for historical reasons involving the 2008–2012 daylight time discrepancies, both zones will continue to be reflected in TZDB. The TZDB administrators will retain the right to keep the identifiers "Asia/Gaza" and "Asia/Hebron", or to change them according to rules that they and the larger community have established. Governments or other bodies do not determine these identifiers, and cannot unilaterally claim the right to do so. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org

1 0

No leap second on 2022-06-30
by Tim Parenti Jan. 11, 2022

Jan. 11, 2022

Per IERS, Bulletin C 63 (2022-01-05) https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.63 …and forwarded below. A patch updating leap-seconds.list from NIST is attached, and is installed in the development repository. -- Tim Parenti ---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc(a)obspm.fr> Date: Wed, 5 Jan 2022 at 10:43 Subject: Bulletin C number 63 To: <bulc.iers(a)obspm.fr> INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE DE L'IERS OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : +33 1 40 51 23 35 e-mail : services.iers(a)obspm.fr http://hpiers.obspm.fr/eop-pc Paris, 05 January 2022 Bulletin C 63 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO leap second will be introduced at the end of June 2022. The difference between Coordinated Universal Time UTC and the International Atomic Time TAI is : from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -37 s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Christian BIZOUARD Director Earth Orientation Center of IERS Observatoire de Paris, France

1 0

Re: [tz] The State of Palestine has adopted the first part of the specification for its time zone
by Paul Eggert Jan. 5, 2022

Jan. 5, 2022

On 1/4/22 09:12, Eliot Lear via tz wrote: > The TZ update process here has no formal recognition of governments (any governments). Still, statements from governments, however they reach this group, tend to carry a lot of weight. Quite true. In the past we've given a lot of weight to official government documents, and we welcome future cooperation in this area as this will streamline communication. (All too often for many countries in the past, we've had to rely on third parties or the popular press to forward their governments' information to us, which has resulted in inaccuracies and delays in updating the database.) From the timekeeping point of view, the most important thing is to know the UTC offsets and the rules for when daylight saving time starts and stops in Palestine, and for technical reasons it's best to have this nailed down well in advance - preferably at least a year before rules change. Currently for Palestine, tzdb lists standard time of UTC+02, and it says daylight saving time starts at 00:00 on the first Saturday on or after March 24, and ends at 01:00 on the first Friday on or after October 23. Unfortunately, as far as I know these daylight saving time rules are not official, in that there's no official Palestinian government document listing these rules for future years; however, tzdb must put *something* in the database and that's the best guess we've come up with. If the government could publish an official document stating what the rules are for future years, we'd be happy to adjust tzdb to match that. Of lesser importance is the English-language abbreviation used for standard and daylight saving time in Palestine. (This is less important because most timekeeping applications do not rely on these abbreviations, as they are inherently ambiguous and somewhat deprecated anyway.) Here, tzdb attempts to follow common practice, and it currently uses the same longstanding abbreviations for time in Palestine that it uses for Cyprus, Egypt, Jordan, Lebanon, and Syria - namely "EET" and "EEDT" (short for "Eastern European Time" and "Eastern European Summer Time"). I am unaware of any English-language use of the abbreviations "PSST" and "PSDT" to refer to civil timekeeping in this area. However, if these abbreviations become popular in common practice we should change tzdb to incorporate them.

2 2

Re: [tz] The State of Palestine has adopted the first part of thespecification for its time zone
by Sanjeev Gupta Jan. 4, 2022

Jan. 4, 2022

On Tue, Jan 4, 2022 at 7:24 PM <heba.hamad(a)mtit.gov.ps> wrote: > What is meant in general is that the State of Palestine (the Palestinian > government) is the only authorized one to address the international > bodies, including IANA, to request any amendment, update, registration, > or anything else related to the subject, > That may be hard to enforce. I am in Singapore, so what happens if I write to this list with information on the time in Hebron, or whether Gaza and Ramallah have the same DST date or not? I would be unauthorised to address IANA and request an update. or to publish any official decisions regarding the time Zone of the State > of Palestine. > Of course. That is unobjectionable. -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane

2 1

[PATCH] Allow complication with tcc
by Arthur Williams Dec. 31, 2021

Dec. 31, 2021

In zic.c, some multi-line strings were surrounded in parenthesis which prevented tcc from parsing it. Maybe this is a complier bug, but don't think we gain anything by having the paren so just removed them. --- zic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zic.c b/zic.c index 1ab636be..867c8d18 100644 --- a/zic.c +++ b/zic.c @@ -990,9 +990,9 @@ random_dirent(char const **name, char **namealloc) char const *src = *name; char *dst = *namealloc; static char const prefix[] = ".zic"; - static char const alphabet[] = ("abcdefghijklmnopqrstuvwxyz" + static char const alphabet[] = "abcdefghijklmnopqrstuvwxyz" "ABCDEFGHIJKLMNOPQRSTUVWXYZ" - "0123456789"); + "0123456789"; enum { prefixlen = sizeof prefix - 1, alphabetlen = sizeof alphabet - 1 }; int suffixlen = 6; char const *lastslash = strrchr(src, '/'); -- 2.34.1

2 1

Re: [tz] Change Request: Europe/Kiev to Europe/Kyiv
by John Hawkinson Dec. 15, 2021

Dec. 15, 2021

A bit of necroposting from my August 2020 email (quoted in full below): > We should take the time to write up a good lengthy explanation of > the issues ("boilerplate"), because this a really important issue of > concern to many people in the world and the project has indeed > thought about it pretty carefully. Dismissing the inquiries because > they are repetitive makes it seem like we haven't, and that > unnecessarily upsets [people]. Has anyone done any work on this, or given thought to it? Serhii Trykoza (hopefully cc'd)'s github PR from the last hour (https://github.com/eggert/tz/pull/35, copied far below) raises the issue again. Please note that the tz project does not use github PRs for issue tracking or commit management, so the PR will likely be closed in short order, which is not an indication of merit. Speaking of boilerplates, I want to again suggest that if this is going to continue to be the project policy, there should be a github pull-request template that makes it clear pull requests are not considered appropriate. Also, when you create a pull request on github now, it reports, "Be sure to review the contributing guidelines." with a hyperlink to https://github.com/eggert/tz/blob/228a93f759cd5f2b0cca9e05eeee3d7cdea07ebf/…. It is not until the last paragraph of that file that any mention is made of pull requests ("[p]lease do not create [them]"), and the fact that the it's a plain text file (rather than CONTRIBUTING.md in markdown) makes it feel pretty unfriendly in the github world. Convertinf the file to markdown and making the "please don't use github pull requests" the first thing, rather than the last thing, would help to get the point across. (Indeed, perhaps that should be the *only* thing in the file that github links to.) -- jhawk(a)alum.mit.edu John Hawkinson John Hawkinson <jhawk(a)alum.mit.edu> wrote on Sat, 15 Aug 2020 at 18:52:58 EDT in <20200815225258.GA62055(a)alum.mit.edu>: > Date: Sat, 15 Aug 2020 18:52:58 -0400 > From: John Hawkinson <jhawk(a)alum.mit.edu> > To: Paul Eggert <eggert(a)cs.ucla.edu>, Victor Perov <vic.gald(a)gmail.com> > Cc: Time zone mailing list <tz(a)iana.org> > Subject: Re: [tz] Change Request: Europe/Kiev to Europe/Kyiv > Message-ID: <20200815225258.GA62055(a)alum.mit.edu> > In-Reply-To: <eggert/tz/pull/27/c673663957(a)github.com> > <cefc7f01-a3e9-f2a4-9ab9-5288147f994a(a)cs.ucla.edu> > > I do not think we have handled this well; we have not given Victor Perov a good answer. Indeed, to some extent we've made it a "runaround." We can do better. > > We should take the time to write up a good lengthy explanation of the issues ("boilerplate"), because this a really important issue of concern to many people in the world and the project has indeed thought about it pretty carefully. Dismissing the inquiries because they are repetitive makes it seem like we haven't, and that unnecessarily upsets peopl. > > Victor Perev: I don't have time for a full write-up right now, but please consult the archives of the tz list (http://mm.icann.org/pipermail/tz/ or perhaps https://www.google.com/search?q=site%3Amm.icann.org%2Fpipermail%2Ftz%2F+kyiv which returns 203 results). The tz project is very conservative in its judgment for when the predominant English spelling of a city has changed, and so far the project has judged that Kiev is still preferred. We discussed it when major English newspapers and style guides changed from Kiev to Kyiv last year (prompted by the US presidential impeachment, which lead to a lot of discussion about Kyiv in America), and we will probably continue to discuss it as time goes on. But we've thought about it and discussed it a lot. The answers you got don't explain that, and that means we have not done a good a job as we should have. Sorry about that. > > In particular, I think Brian Inglis's answer was actually incorrect in a way that really matters ("Kiev is the correct English spelling"). > There are multiple correct English spellings. It used to be that Kiev was the only one, but Kyiv is gaining popularity more and more. > > > Paul Eggert <eggert(a)cs.ucla.edu> wrote on Sat, 15 Aug 2020 > at 18:19:08 EDT in <cefc7f01-a3e9-f2a4-9ab9-5288147f994a(a)cs.ucla.edu>: > > > Thanks for bringing that to the mailing list (if I could shut off GitHub > > pull requests I would). > > Although you cannot do so, we can handle them a little bit better. > Please see https://docs.github.com/en/github/building-a-strong-community/creating-a-pu… > > You can create a template that explains to a would-be pull request submitter than pull requests will be closed and the project uses the mailing list for development discussions. ("I understand that the tz project does not use pull requests on github, and that if I enter a pull request here, it will be closed and I will be directed to send email to tz(a)iana.org.") > > For the particular case of regular, recurring issues, it may be worth while to keep one of #15, #26, and #27 open and mark the others as a duplicate of it, so that it is easier for newcomers to understand that this issue has been carefully considered and is not a simple oversight. > > https://github.com/eggert/tz/pulls?q=kiev > > Also, not to pick on Brian (again), but if the project policy is not to use github pull requests, it's not great to respond to pull requests on their substance, because it bifurcates the discussion and makes it seem like we actually do use pull requests ("except when we don't"). So what seems like a helpful thing may not be. > > -- > jhawk(a)alum.mit.edu > John Hawkinson Serhii Trykoza <notifications(a)github.com> wrote on Mon, 6 Dec 2021 at 08:17:35 EST in <eggert/tz/pull/35(a)github.com>: > Date: Mon, 06 Dec 2021 05:17:35 -0800 > From: Serhii Trykoza <notifications(a)github.com> > To: eggert/tz <tz(a)noreply.github.com> > Cc: Subscribed <subscribed(a)noreply.github.com> > Subject: [eggert/tz] KyivNotKiev (PR #35) > Reply-To: eggert/tz > <reply+AAJWHPTK2DO6A5B34PZOC3N7XHXG7EVBNHHD7Z4WBI(a)reply.github.com> > Message-ID: <eggert/tz/pull/35(a)github.com> > X-GitHub-Sender: strikoza > > In September 2020, the English Wikipedia switched from using Kiev to Kyiv. > > https://en.wikipedia.org/wiki/KyivNotKiev > You can view, comment on, or merge this pull request online at: > > https://github.com/eggert/tz/pull/35 > > -- Commit Summary -- > > * KyivNotKiev - In September 2020, the English Wikipedia switched from using Kiev to Kyiv - https://en.wikipedia.org/wiki/KyivNotKiev > > -- File Changes -- > > M .gitignore (2) > M europe (4) > M theory.html (2) > M zone.tab (2) > M zone1970.tab (2) > > -- Patch Links -- > > https://github.com/eggert/tz/pull/35.patch > https://github.com/eggert/tz/pull/35.diff > > -- > You are receiving this because you are subscribed to this thread. > Reply to this email directly or view it on GitHub: > https://github.com/eggert/tz/pull/35

4 9

[PATCH] Fix "el ds" typo in man pages
by Paul Eggert Dec. 14, 2021

Dec. 14, 2021

This fixes a typo that I introduced in 2014 when fixing glitches with '-' and italics in man pages. The typo is visible only when using traditional troff (as opposed to groff-compatible processors). --- date.1 | 2 +- newctime.3 | 2 +- newstrftime.3 | 2 +- newtzset.3 | 2 +- time2posix.3 | 2 +- tzfile.5 | 2 +- tzselect.8 | 2 +- zdump.8 | 2 +- 8 files changed, 8 insertions(+), 8 deletions(-) diff --git a/date.1 b/date.1 index 432cab1..1ecd63a 100644 --- a/date.1 +++ b/date.1 @@ -5,7 +5,7 @@ date \- show and set date and time .if n .nh .if n .na .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B date [ .B \*-u diff --git a/newctime.3 b/newctime.3 index cc56e2c..1b1790f 100644 --- a/newctime.3 +++ b/newctime.3 @@ -4,7 +4,7 @@ asctime, ctime, difftime, gmtime, localtime, mktime \- convert date and time .SH SYNOPSIS .nf .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B #include <time.h> .PP .BR "extern char *tzname[];" " /\(** (optional) \(**/" diff --git a/newstrftime.3 b/newstrftime.3 index 887aba5..d68bc33 100644 --- a/newstrftime.3 +++ b/newstrftime.3 @@ -41,7 +41,7 @@ strftime \- format date and time .SH SYNOPSIS .nf .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B #include <time.h> .PP .B "size_t strftime(char *restrict buf, size_t maxsize," diff --git a/newtzset.3 b/newtzset.3 index 05aa350..8aaa0ff 100644 --- a/newtzset.3 +++ b/newtzset.3 @@ -4,7 +4,7 @@ tzset \- initialize time conversion information .SH SYNOPSIS .nf .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B #include <time.h> .PP .B timezone_t tzalloc(char const *TZ); diff --git a/time2posix.3 b/time2posix.3 index fbb5766..2ea7edc 100644 --- a/time2posix.3 +++ b/time2posix.3 @@ -4,7 +4,7 @@ time2posix, posix2time \- convert seconds since the Epoch .SH SYNOPSIS .nf .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B #include <time.h> .PP .B time_t time2posix(time_t t); diff --git a/tzfile.5 b/tzfile.5 index e2f11b4..550b31d 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -10,7 +10,7 @@ tzfile \- timezone information \\$3\*(lq\\$1\*(rq\\$2 .. .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- The timezone information files used by .BR tzset (3) are typically found under a directory with a name like diff --git a/tzselect.8 b/tzselect.8 index a1ec8d0..69514e2 100644 --- a/tzselect.8 +++ b/tzselect.8 @@ -3,7 +3,7 @@ tzselect \- select a timezone .SH SYNOPSIS .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B tzselect [ .B \*-c diff --git a/zdump.8 b/zdump.8 index a5e2042..131a6cb 100644 --- a/zdump.8 +++ b/zdump.8 @@ -17,7 +17,7 @@ zdump \- timezone dumper \\$3\*(lq\\$1\*(rq\\$2 .. .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- The .B zdump program prints the current time in each -- 2.32.0

1 0

[PROPOSED] Fix Y2242 bug in tzdb tarball generation
by Paul Eggert Dec. 14, 2021

Dec. 14, 2021

Use pax format so that ‘make tarballs’ will still work after the year 2242. Without this patch, a far-future ‘make tarballs’ would fail for the same reason the following fails now with GNU tar: $ touch -d 2242-03-16T12:56:32Z future $ tar --format=ustar -cf tar future tar: value 8589934592 out of time_t range 0..8589934591 tar: Exiting with failure status due to previous errors This patch doesn’t change the tarball format for today’s releases since we don’t use any features requiring pax format, which means the tarballs stick to the ustar subset of pax. Although this issue was exposed by the recent switch to ustar format, the Y2242 bug has been present since the tzdb project began, due to historical tar format expiring in 2242 and to POSIX and GNU coming up with incompatible extensions to deal with this expiration. * Makefile (GNUTARFLAGS): Switch from --format=ustar to --format=pax --pax-option='delete=atime,delete=ctime'. * NEWS: Update description of tarball format change. --- Makefile | 3 ++- NEWS | 7 +++++-- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index d30227a..23dcc14 100644 --- a/Makefile +++ b/Makefile @@ -466,7 +466,8 @@ OK_LINE= '^'$(OK_CHAR)'*$$' # Flags to give 'tar' when making a distribution. # Try to use flags appropriate for GNU tar. -GNUTARFLAGS= --format=ustar --numeric-owner --owner=0 --group=0 \ +GNUTARFLAGS= --format=pax --pax-option='delete=atime,delete=ctime' \ + --numeric-owner --owner=0 --group=0 \ --mode=go+u,go-w --sort=name TARFLAGS= `if tar $(GNUTARFLAGS) --version >/dev/null 2>&1; \ then echo $(GNUTARFLAGS); \ diff --git a/NEWS b/NEWS index edb9a1d..1106ef6 100644 --- a/NEWS +++ b/NEWS @@ -26,9 +26,12 @@ Unreleased, experimental changes instead of GNU format. Although the formats are almost identical for these tarballs, ustar headers' magic fields contain "ustar" instead of "ustar ", and their version fields contain "00" instead - of " ". For details about ustar format, please see + of " ". The two formats are planned to diverge more significantly + for tzdb releases after 2242-03-16 12:56:31 UTC, when the ustar + format becomes obsolete and the tarballs switch to pax format, an + extension of ustar. For details about these formats, please see "pax - portable archive interchange", IEEE Std 1003.1-2017, - <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_…>. + <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_…>. Changes affecting documentation and commentary -- 2.33.1

2 1

[PATCH 1/4] Simplify tzselect by omitting old Bash workaround
by Paul Eggert Dec. 13, 2021

Dec. 13, 2021

* tzselect.ksh (doselect): Omit Bash 1.14.7 workaround that I wrote in September 1996, as Bash 1.14.7 hasn’t been supported for years and surely should not be used anyway for security reasons. Bash 2.0 came out in December 1996. --- tzselect.ksh | 8 -------- 1 file changed, 8 deletions(-) diff --git a/tzselect.ksh b/tzselect.ksh index 18fce27..832cf75 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -101,14 +101,6 @@ then esac done || exit } - - # Work around a bug in bash 1.14.7 and earlier, where $PS3 is sent to stdout. - case $BASH_VERSION in - [01].*) - case `echo 1 | (select x in x; do break; done) 2>/dev/null` in - ?*) PS3= - esac - esac ' else doselect() { -- 2.32.0

1 3