March 2021 - tz - lists.iana.org

Palestine summer time 2021
by Sharef Mustafa March 24, 2021

March 24, 2021

Hi, Palestine to start summer time on Sat Mar 27th after midnight as per cabinet announcement "وأقر مجلس الوزراء بدء التوقيت الصيفي في دولة فلسطين، بتقديم عقارب الساعة 60 دقيقة، اعتبارا من منتصف ليل الجمعة/ السبت الموافق 27-3-2021" "The Council of Ministers approved the start of daylight saving time in the State of Palestine, by presenting the clock at 60 minutes, starting at midnight Friday / Saturday 27-3-2021 " https://www.facebook.com/PMO.Palestine/posts/4198242146875242 https://www.maannews.net/news/2035719.html BR

3 2

[PROPOSED] Fix ‘make check_time_t_alternatives’
by Paul Eggert March 24, 2021

March 24, 2021

* zic.c (EPOCH_LOCAL, EPOCH_OFFSET, time_tz): #undef, so that zic uses the system ‘time’ function instead of relying on any replacement. That way, zic doesn’t depend on localtime.c. This fixes a problem introduced in 2021-02-23T07:03:07Z!eggert@cs.ucla.edu when zic.c started using the ‘time’ function to generate crude random numbers. --- zic.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/zic.c b/zic.c index 6c38bd7..d1e9a97 100644 --- a/zic.c +++ b/zic.c @@ -5,6 +5,12 @@ ** 2006-07-17 by Arthur David Olson. */ +/* Use the system 'time' function, instead of any private replacement. + This avoids creating an unnecessary dependency on localtime.c. */ +#undef EPOCH_LOCAL +#undef EPOCH_OFFSET +#undef time_tz + #include "version.h" #include "private.h" #include "tzfile.h" -- 2.27.0

1 0

[PATCH] Restore simpler delta_nonneg code.
by Paul Eggert March 24, 2021

March 24, 2021

* zdump.c (delta_nonneg): Undo previous change to this area that inadvertently installed an unnecessary ‘if’. --- zdump.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/zdump.c b/zdump.c index e1db329..918d09c 100644 --- a/zdump.c +++ b/zdump.c @@ -716,16 +716,10 @@ hunt(timezone_t tz, char *name, time_t lot, struct tm *lotmp, time_t hit, static intmax_t delta_nonneg(struct tm *newp, struct tm *oldp) { - register intmax_t result; - register int tmy; - - result = 0; - tmy = oldp->tm_year; - if (newp->tm_year - tmy > YEARSPERREPEAT) { - intmax_t cycles = (newp->tm_year - tmy) / YEARSPERREPEAT; - result = cycles * (YEARSPERREPEAT * DAYSPERNYEAR + 100 - 4 + 1); - tmy += cycles * YEARSPERREPEAT; - } + intmax_t oldy = oldp->tm_year; + int cycles = (newp->tm_year - oldy) / YEARSPERREPEAT; + intmax_t sec = SECSPERREPEAT, result = cycles * sec; + int tmy = oldp->tm_year + cycles * YEARSPERREPEAT; for ( ; tmy < newp->tm_year; ++tmy) result += DAYSPERNYEAR + isleap_sum(tmy, TM_YEAR_BASE); result += newp->tm_yday - oldp->tm_yday; -- 2.27.0

1 0

zoneinfo generating issues
by 汪蒙蒙（木之） March 17, 2021

March 17, 2021

Hi: Recently, I wanted to write a program to watch the change of timezone database. I got newest version from this address: https://data.iana.org/time-zones/releases/tzdata2021a.tar.gz. I used zic (version: zic (tzcode) 2020c, system: CentOS Linux release 7.6.1810 (Core)) to generate the zoneinfo. I pick up some zones with local timeto calculate utc time to verify the changes using both the new and currently used version tzdata, here is diff: zone local time by 2021a utc time by 2020d utc time America/Adak 2022-11-01 00:00:00 2022-11-01 09:00:00 2022-11-01 10:00:00 America/Anchorage 2022-11-01 00:00:00 2022-11-01 08:00:00 2022-11-01 09:00:00 America/Asuncion 2022-10-01 00:00:00 2022-10-01 04:00:00 2022-10-01 03:00:00 America/Atka 2022-11-01 00:00:00 2022-11-01 09:00:00 2022-11-01 10:00:00 Those zones are not changed from version 2020d to 2021a. I am very confused and not sure if I generated the zoneinfo in the right way. Here was what do: # mkdir zoneinfo # cd tzdata2021a # zic -d ../zoneinfo -L ./leapseconds africa antarctica asia australasia europe northamerica southamerica etcetera backward factory I was wondering if you could provide me some help. I really appreciate your reply. Sincerely, wangmm

11 27

Should tzfile.5 list the time zone designations field more explicitly?
by Ian Abbott March 17, 2021

March 17, 2021

The description of the local time types entries mentions the array of time zone abbreviation bytes in passing, but that probably deserves its own list item. On skimming over the man page, it looks like the local time type entries are immediately followed by the leap-second correction records. -- -=( Ian Abbott <abbotti(a)mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-

2 2

[PROPOSED] Improve coverage of version 4 interoperability
by Paul Eggert March 17, 2021

March 17, 2021

* tzfile.5: Mention problems with version 3-only readers and version 4 files, and update other interoperability coverage. --- tzfile.5 | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/tzfile.5 b/tzfile.5 index 8ee6cfb..b4952d5 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -243,10 +243,13 @@ Readers that only understand Version 1 must ignore any data that extends beyond the calculated end of the version 1 data block. .PP -Writers should generate a version 3 file if +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 +and so does not use version 4 features, but TZ string extensions are necessary to accurately -model transition times. -Otherwise, version 2 files should be generated. +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 @@ -269,7 +272,7 @@ and This is for compatibility with POSIX requirements for time zone abbreviations. .PP -When reading a version 2 or 3 file, readers +When reading a version 2+ file, readers should ignore the version 1 header and data block except for the purpose of skipping over them. .PP @@ -328,6 +331,10 @@ for the next time zone east, e.g., .q "AST4" 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. +.IP * Some readers ignore the footer, and instead predict future timestamps from the time type of the last transition. As a partial workaround, a writer can output more transitions -- 2.27.0

1 0

[PATCH 1/7] localtime.c is less finicky about leap seconds
by Paul Eggert March 17, 2021

March 17, 2021

* localtime.c (tzloadbody): Do not reject a TZif file merely because its leap second table contains adjacent entries with equal corrections, or contains a first entry with a correction value other than +1 or -1. * NEWS: Mention this. --- NEWS | 5 +++++ localtime.c | 13 ++++++++++--- 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index 0de05f3..d8676e6 100644 --- a/NEWS +++ b/NEWS @@ -39,6 +39,11 @@ Unreleased, experimental changes seconds error than with an hour error, so zic -L no longer truncates output in this way. + The TZif reader now allows the leap second table to begin with a + correction other than -1 or +1, and to contain adjacent + transitions with equal corrections. This supports possible + future extensions to the TZif format. + 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/localtime.c b/localtime.c index 6627ff2..a086d4d 100644 --- a/localtime.c +++ b/localtime.c @@ -445,7 +445,7 @@ tzloadbody(char const *name, struct state *sp, bool doextend, int_fast32_t ttisstdcnt = detzcode(up->tzhead.tzh_ttisstdcnt); int_fast32_t ttisutcnt = detzcode(up->tzhead.tzh_ttisutcnt); int_fast64_t prevtr = 0; - int_fast32_t prevcorr = 0; + int_fast32_t prevcorr; int_fast32_t leapcnt = detzcode(up->tzhead.tzh_leapcnt); int_fast32_t timecnt = detzcode(up->tzhead.tzh_timecnt); int_fast32_t typecnt = detzcode(up->tzhead.tzh_typecnt); @@ -542,9 +542,16 @@ tzloadbody(char const *name, struct state *sp, bool doextend, and UTC months are at least 28 days long (minus 1 second for a negative leap second). Each leap second's correction must differ from the previous one's by 1 - second. */ + second or less, except that the first correction can be + any value; these requirements are more generous than + RFC 8536, to allow future RFC extensions. */ if (tr - prevtr < 28 * SECSPERDAY - 1 - || (corr != prevcorr - 1 && corr != prevcorr + 1)) + || ((timecnt == 0 || sp->ats[0] < tr) + && ! (i == 0 + || (prevcorr < corr + ? corr == prevcorr + 1 + : (corr == prevcorr + || corr == prevcorr - 1))))) return EINVAL; sp->lsis[leapcnt].ls_trans = prevtr = tr; sp->lsis[leapcnt].ls_corr = prevcorr = corr; -- 2.27.0

2 7

changing "master" to "main" in tzdb development repository
by Paul Eggert March 17, 2021

March 17, 2021

Because the word "master" has negative connotations in English, I renamed the "master" branch to "main" in the tzdb development repository <https://github.com/eggert/tz>. This follows in the wake of GitHub's October change that makes the default branch "main" rather than "master", and GitHub's followup changes in January that made renaming relatively painless - for example, web requests for "master" are now redirected to "main" automatically <https://github.com/github/renaming/>. This renaming by GitHub is part of a broader change within the Git software ecosystem <https://sfconservancy.org/news/2020/jun/23/gitbranchname/>. This change affects neither past nor future releases of tzdb. It affects only the small number of direct accesses to the development repository for commits between releases. The idea is that on balance the small inconvenience for developers is outweighed by the advantage in reducing insensitivity overall. If you are a developer with a local clone of the tzdb repository, please adjust to this change by running the following shell commands: $ git branch -m master main $ git fetch origin $ git branch -u origin/main main I've done this for my own local clone of the repository. To document this change for tzdb newcomers, I installed the attached patch to the CONTRIBUTING file just before renaming the branch.

8 8

Troubles with zone Asia/Gaza after tzdata2020b release
by Evgheni Antropov March 15, 2021

March 15, 2021

Dear tzdata maintainers, I have found that after tzdata2020b release something has gone wrong with Asia/Gaza timezone, which is related to Palestine. For checking I used this information https://www.timeanddate.com/worldclock/palestine/gaza and for DST at 2019: https://www.timeanddate.com/time/change/palestine/gaza?year=2019 for DST at 2020: https://www.timeanddate.com/time/change/palestine/gaza?year=2020 for DST at 2021: https://www.timeanddate.com/time/change/palestine/gaza?year=2021 I compiled all last release of tzdata from 2019c to 2021a and was comparing them with Ubuntu packages for 2020b on groovy (20.10) and 2021a on bionic (18.04). If several changes in the date of DST for different years can be related with last applied laws of DST in Palestine (described here http://mm.icann.org/pipermail/tz/2020-October/029376.html) but broken timezone output in letters or numbers is speaking about any error in the this time zone code. Can you investigate this too ? On screenshot you can see all my investigation: [cid:image002.png@01D70EDB.BE0D5350] Also I share all commands and listing for your execution itself: [root@Router8:~]# ls -la /etc/localtime lrwxrwxrwx 1 root root 35 Mar 4 2021 /etc/localtime -> /usr/share/zoneinfo/posix/Asia/Gaza [root@Router8:~]# ls -la /usr/share/zoneinfo/posix/Asia/Gaza* lrwxrwxrwx 1 root root 41 Mar 27 01:00 /usr/share/zoneinfo/posix/Asia/Gaza -> /usr/share/zoneinfo/posix/Asia/Gaza.2019c -rw-r--r-- 1 root root 2316 Oct 22 09:34 /usr/share/zoneinfo/posix/Asia/Gaza.2019c -rw-r--r-- 1 root root 2316 Oct 30 2020 /usr/share/zoneinfo/posix/Asia/Gaza.2020a -rw-r--r-- 1 root root 1166 Oct 30 2020 /usr/share/zoneinfo/posix/Asia/Gaza.2020b -rw-r--r-- 1 root root 1166 Oct 30 2020 /usr/share/zoneinfo/posix/Asia/Gaza.2020c -rw-r--r-- 1 root root 1195 Oct 30 2020 /usr/share/zoneinfo/posix/Asia/Gaza.2020d -rw-r--r-- 1 root root 1213 Mar 1 2021 /usr/share/zoneinfo/posix/Asia/Gaza.2021a -rw-r--r-- 1 root root 2316 Oct 19 2020 /usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2020b -rw-r--r-- 1 root root 2459 Jan 27 2021 /usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2021a [root@Router8:~]# date +"%Y%m%d %T" -s "20190328 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20190328 23:59:55 Thu Mar 28 23:59:59 2019 +0200 EET Fri Mar 29 01:00:01 2019 +0300 EEST [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.2020a /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.2020a' [root@Router8:~]# date +"%Y%m%d %T" -s "20200326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20200326 23:59:55 Thu Mar 26 23:59:59 2020 +0200 EET Fri Mar 27 01:00:01 2020 +0300 EEST [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.2020b /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.2020b' [root@Router8:~]# date +"%Y%m%d %T" -s "20200326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20200326 23:59:55 Thu Mar 26 23:59:59 2020 +0000 Fri Mar 27 00:00:01 2020 +0000 [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.2020c /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.2020c' [root@Router8:~]# date +"%Y%m%d %T" -s "20200326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20200326 23:59:55 Thu Mar 26 23:59:59 2020 +0000 Fri Mar 27 00:00:01 2020 +0000 [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2020b /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2020b' [root@Router8:~]# date +"%Y%m%d %T" -s "20200326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20200326 23:59:55 Thu Mar 26 23:59:59 2020 +0200 EET Fri Mar 27 01:00:01 2020 +0300 EEST [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.2021a /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.2021a' [root@Router8:~]# date +"%Y%m%d %T" -s "20210326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20210326 23:59:55 Fri Mar 26 23:59:59 2021 +0000 Sat Mar 27 00:00:01 2021 +0000 [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2021a /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2021a' [root@Router8:~]# date +"%Y%m%d %T" -s "20210326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20210326 23:59:55 Fri Mar 26 23:59:59 2021 +0200 EET Sat Mar 27 01:00:01 2021 +0300 EEST Best regards, [cid:image001.jpg@01D70EC7.959CF010] Evgheni Antropov Software R&D Engineer +373 22 404 665 www.addgrup.com<http://www.addgrup.com/>

4 12

Re: [tz] [PROPOSED] Fix Sierra Leone typo for 1957
by REMI ACIEN March 11, 2021

March 11, 2021

For Sierra Leone : -0:53:00 - FMT 1913 Jun # Freetown Mean Time. Envoyé depuis mon appareil Galaxy

2 1