- tz - lists.iana.org

Issue with timezone
by Ty Hanks July 18, 2023

July 18, 2023

Having an issue with timezone ‘America/Bogota’ should be the same as ‘America/NewYork’ but if you pull time based on it from pytz which uses your database. You get the wrong timezone a 3 or 4 hour ahead timezone. Feel free to ask for more testing info if needed .. Thanks

4 3

TZDB 2023c build issues with ARM busybox
by Rajesh Subramanian July 11, 2023

July 11, 2023

Hi Team, I am trying to compile the TZDB in ARM busysbox version: 2023c After compiling the executable during the installation stage, got an error while trying to create the timezone files using tzdata.zi. Could you please help on what is wrong here? make BACKWARD='backward' DESTDIR='/home/rajesh/code/iss/build/ISS-MVL-ARM-IM/niagara-staging/tmp/tz' LEAPSECONDS='' PACKRATDATA='' PACKRATLIST='' TZDEFAULT='/etc/localtime' TZDIR='/usr/share/zoneinfo' ZIC='./zic ' LEAPSECONDS= install_data make[1]: Entering directory '/home/rajesh/code/iss/build/ISS-MVL-ARM-IM/tz/tz-2023c' ./zic -v -d '/home/rajesh/code/iss/build/ISS-MVL-ARM-IM/niagara-staging/tmp/tz/usr/share/zoneinfo' tzdata.zi *./zic: 1: Syntax error: word unexpected (expecting ")")* make[1]: *** [Makefile:697: install_data] Error 2 File format for the executable: file zic is linked with the expected host architecture. *zic*: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=48cd5d62692908a4f58468f5077d4187fe06c825, not stripped Regards, Rajesh

4 3

Error in Scandinavian tz data
by Anders Rosendahl June 28, 2023

June 28, 2023

Hello! I'm developing an application using the JavaScript Intl API (which is relying on the IANA tz db) for converting between local time and UTC. I started receiving error reports from users about wrong calculations (particularly from Denmark in the 1940's), and I discovered that in some cases daylight saving time was applied in a way not in accordance to historical facts. I investigated the IANA tz database files and I discovered that a change has happened in version 2022b (in the file "europe"). Compared to the earlier version (2022a), 4 zones seem to have their rules removed and instead linked to Europe/Berlin: Link Europe/Berlin Arctic/Longyearbyen Link Europe/Berlin Europe/Copenhagen Link Europe/Berlin Europe/Oslo Link Europe/Berlin Europe/Stockholm This, evidently, is not correct, and will result in erroneous results for these zones. Best wishes, Anders Rosendahl

7 11

Re: [tz] [libc-coord] thread-safe localtime() for an arbitrary timezone
by Paul Eggert June 21, 2023

June 21, 2023

On 2023-06-15 10:03, enh wrote: > any thoughts on either renaming `struct state` (i went with `struct > __timezone_t` to match the typedef to timezone_t for the pointer) or having > a knob for that (i added a `#define state __timezone_t` in the `#if > NETBSD_INSPIRED` in private.h)? why do i care? because tzcode pulls in the > system <time.h>, which is actually fine for the tzcode code, but breaks the > OpenBSD wcsftime(). We could rename 'struct state', but I'm a bit lost as to what the problem is, as I don't see mention of 'state' or 'timezone_t' in openbsd/lib/libc/time/wcsftime.c. Although there is a 'struct state' in openbsd/lib/libc/time/localtime.c I assume you're replacing that with tzcode's localtime.c somehow. User apps (which tzcode is, by default) shouldn't define symbols like __timezone_t because these symbols are reserved to the system. We could easily rename 'struct state' to 'struct timezone_struct' so that you could compile with -Dtimezone_struct=__timezone_t, though I'm still curious about why 'struct state' causes problems. I'll cc this to the tz mailing list to see whether other people there have insight into this issue. For those new to the discussion, the original thread is archived here: https://www.openwall.com/lists/libc-coord/2023/06/14/1

4 14

Iran Time Zone is Incorrect in Your Database
by Mohammad Ahmadian June 2, 2023

June 2, 2023

Hello, Thanks for your service. This year, the Iran government decided to cancel the daylight time zone. So they did not change the time zone to 04:30. It is now 03:30. I updated my tablet via this application to the latest version of your database successfully: https://github.com/meefik/tzupdater But the time zone is wrongly 04:30 again. Please change your database. Let me know what you think and do. Thank you

2 1

Tzdb build issue
by Naveen kumar June 1, 2023

June 1, 2023

Hi Team, I am facing this issue while compiling the tzdata latest version tzdb-2023c.I attached the log for your reference. Thanks, Naveen.

4 9

[PROPOSED] Update tzselect comment
by Paul Eggert June 1, 2023

June 1, 2023

* tzselect.ksh: Update comment, as Oracle has extended the end-of-life date for Solaris 10. --- tzselect.ksh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tzselect.ksh b/tzselect.ksh index 9a91acfc..98774c03 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -21,7 +21,7 @@ REPORT_BUGS_TO=tz(a)iana.org # MirBSD Korn Shell <http://www.mirbsd.org/mksh.htm> # # For portability to Solaris 10 /bin/sh (supported by Oracle through -# January 2024) this script avoids some POSIX features and common +# January 2025) this script avoids some POSIX features and common # extensions, such as $(...) (which works sometimes but not others), # $((...)), ! CMD, ${#ID}, ${ID##PAT}, ${ID%%PAT}, and $10. -- 2.39.2

2 1

[PATCH] Ask for POSIX-conforming ‘make’
by Paul Eggert May 31, 2023

May 31, 2023

* Makefile (.POSIX): New target. I discovered the need for this when I ran ‘make -n’ and GNU Make executed recipe lines containing $(MAKE) even though they had side effects. When run in POSIX mode, GNU Make won’t execute recipe lines unless they begin with ‘+’. POSIX says the behavior of ‘make’ is undefined unless the Makefile’s first non-comment line has a ‘.POSIX’ target. --- Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile b/Makefile index 8017a14e..da3ee259 100644 --- a/Makefile +++ b/Makefile @@ -1,4 +1,6 @@ # Make and install tzdb code and data. +# Request POSIX conformance; this must be the first non-comment line. +.POSIX: # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. -- 2.39.2

1 0

Europe/Tiraspol problem
by Yoshito Umaoka May 19, 2023

May 19, 2023

Dear all, I was looking at some Unicode ICU test failure on Ubuntu related to time zone. ICU utilizes TZ database including backward file. In backward file, Europe/Tiraspol is defined as a link of Europe/Chisinau. So the actual rule is coming from Europe/Chisinau as below (2023c) # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Europe/Chisinau 1:55:20 - LMT 1880 1:55 - CMT 1918 Feb 15 # Chisinau MT 1:44:24 - BMT 1931 Jul 24 # Bucharest MT 2:00 Romania EE%sT 1940 Aug 15 2:00 1:00 EEST 1941 Jul 17 1:00 C-Eur CE%sT 1944 Aug 24 3:00 Russia MSK/MSD 1990 May 6 2:00 2:00 Russia EE%sT 1992 2:00 E-Eur EE%sT 1997 # See Romania commentary for the guessed 1997 transition to EU rules. 2:00 Moldova EE%sT I found behavior of Europe/Tiraspol is different on Ubuntu. When I set Europe/Tiraspol as the system time zone, the default offset set to timezone variable becomes -10800 (3 hour ahead of UTC). However, Europe/Chisinau above shows it should be -7200 (2 hour ahead of UTC) at this moment. (POSIX timezone variable should store “standard offset”, not counting daylight adjustment). On Ubuntu, when I set Europe/Tiraspol as system time zone, -10800 is set to timezone variable. However, when I set Europe/Chisinau, it changes to -7200. Then I realized Ubuntu is using backzone file, which contains different rule. In backzone file, Europe/Tiraspol is defined as below (2023c) # Moldova / Transnistria Zone Europe/Tiraspol 1:58:32 - LMT 1880 1:55 - CMT 1918 Feb 15 # Chisinau MT 1:44:24 - BMT 1931 Jul 24 # Bucharest MT 2:00 Romania EE%sT 1940 Aug 15 2:00 1:00 EEST 1941 Jul 17 1:00 C-Eur CE%sT 1944 Aug 24 3:00 Russia MSK/MSD 1991 Mar 31 2:00 2:00 Russia EE%sT 1992 Jan 19 2:00 3:00 Russia MSK/MSD I understand backzone was created for preserving zone definition of some locations which only differs pre-1970 date, and these data might not be reliable. In reality, I think most of TZ database consumer still rely on either backward or backzone for backward compatibility. I think it’s problematic if these two files produce different results today. I guess the zone definition in backzone file might be outdated, and Tiraspol is actually UTC+2/+3. -Yoshito

2 1

Buggy %z behaviour in strftime
by Almaz Mingaleev May 16, 2023

May 16, 2023

Attached code prints "+0000 America/Los_Angeles" both with glibc and with linked ToT strftime implementation. On MacOs it prints "-0800 America/Los_Angeles". Is it a known issue?

10 19

Changes to DST in IR/Tehran timezone
by Jafari Abolfazl May 16, 2023

May 16, 2023

Hello. First of all thanks for maintaining database and second I hav to excuse for my English before hand, cause I am not a native and maybe do some mistakes. Due to goverments choices, starting from 21st March 2023, Iran dismissed DST and now time should stay at +3:30, but due to lack of contacting with official channels, it seems lots of systems still use 2023c tz database and time is +4:30. This problem cause so many problem specially in smartphone that due to lack of automatic time, many application won't work correctly.

3 2

Web sites using recent versions of the tz database
by Sylvia May 10, 2023

May 10, 2023

Dear team, My name is Silvia, I am the webmaster responsible for carta-natal.es. This is an astrology website wich uses the latest version of the TZ database for calculating astral charts with the correct UT hour and date. It includes a section where you can see the timezone details and time changes of each town throughout history: https://carta-natal.es/zona_horaria.php https://carta-natal.es/cambios_horarios.php Of course there could be some (mine/human) error in associating a time zone identifier to each locality. Do you think it would be possible and/or useful to add carta-natal.es to the web sites list at https://carta-natal.es/cambios_horarios.php? Thank you very much. kind regards, Silvia

1 1

More prominent/consistent record of rule change notification date?
by Jan Harris May 8, 2023

May 8, 2023

Greetings I deal with getting the TZ updates rolled out for IBM AIX. As we all know, sometimes IANA is notified in the eleventh hour, and it is not feasible for AIX to deliver fixes in a matter of weeks (or less) Take Egypt, for example. For good reason, IANA did initiate a new build on March 1, as discussed in this thread<https://mm.icann.org/pipermail/tz/2023-March/032683.html>. (Even if they did, it would have been a tight schedule for AIX to have ready mid April.) I certainly appreciate the emphasis on notifications, placed in the IANA article. How Time Zones Are Coordinated<https://www.icann.org/en/blogs/details/how-time-zones-are-coordinated-13-03…> * https://www.icann.org/en/blogs/details/how-time-zones-are-coordinated-13-03… I have incorporated this message in to our AIX TZ documentation. We usually see some attribution to the notification in the NEWS Starting in 2023, Egypt will observe DST from April's last Friday through October's last Thursday. (Thanks to Ahmad ElDardiry.) Assume the transition times are 00:00 and 24:00, respectively. I think it would be helpful if there was a clear record of WHEN IANA is officially notified of TZ changes, so users could understand this is the result of their government changes, and notification processes, it is not a "defect" in how IANA or vendors roll out these updates. I do realize that sometimes “official” notifications seems to be that someone submitted a more formal government reference, instead of a news article. Maybe just an indicator of when the group is provided such official confirmation. Thanks for your consideration! Jan Harris SME: Globalization, Graphics, X11, Desktop, Commands/Auth AIX Development Support Organization - IBM O: Austin, TX 901:3i019 Ph: 1-512-286-5445 Jabber:23635445 E: janhar(a)us.ibm.com <mailto:janhar@us.ibm.com>

6 8

Inconsistencies between backward and backzone
by Benjamin Drung May 4, 2023

May 4, 2023

Hi, building tz with PACKRATDATA=backzone should result in time zones that only differ for dates before 1970. For dates after 1970 they should be identical to not building with PACKRATDATA=backzone (using backzone to create symlinks). But there are four (five if you include Pacific/Enderbury) time zones that has different UTC offset nowadays: * America/Ensenada differs from America/Tijuana * Asia/Kashgar differs from Asia/Urumqi * Atlantic/Jan_Mayen differs from Europe/Berlin * Europe/Tiraspol differs from Europe/Chisinau First investigation indicate that the timezones in backzone did not get the recent updates applied to them. -- Benjamin Drung Debian & Ubuntu Developer

2 3

Introduce Etc/UTC+x timezones?
by Benjamin Drung May 4, 2023

May 4, 2023

Hi, If people are aware of timezones, they often know UTC and their offsets (e.g. Europe/Berlin is UTC+2 summer). But they are probably not aware that the Etc/GMT offsets are inverted (e.g. you have to select Etc/GMT-2 for UTC+2). I was not aware of that and other people as well as the bugs in Ubuntu and Debian indicate (see https://launchpad.net/bugs/1325949 and https://bugs.debian.org/540305) What do you think about the idea of introducing Etc/UTC+x timezones that have the "correct" offset so that people can select fixed offsets more easily? So Etc/GMT-2 would be renamed to Etc/UTC+2 and Etc/GMT-2 would become a symlink to it (same for all other Etc/GMT+x and Etc/GMT-x timezones). -- Benjamin Drung Debian & Ubuntu Developer

16 31

DST changes for Egypt
by Eugen Cravciuc May 3, 2023

May 3, 2023

Hi. May you please update the values for the DST Egypt? Thank you https://www.timeanddate.com/time/change/egypt

2 1

offtime_r
by Dag-Erling Smørgrav April 26, 2023

April 26, 2023

The tzcode distribution includes a (non-standard and undocumented) offtime() function but no offtime_r() function, which seems like an oversight. The attached patch (relative to 2023c) adds it. Regards, Dag-Erling

2 3

Change Chile/Santiago DST
by Antonio Afranio Barbosa Martins April 26, 2023

April 26, 2023

Hi there, There is a issue with Daylight Saving Time (DST) for Chile/Santiago (South America). Based on some sites like https://www.timeanddate.com/time/zone/chile/santiago and https://www.bcn.cl/leychile/navegar?i=1179983&f=2022-08-13 (oficial Chile resolution) Correct time: Year Daily Time Change 2022 Sun, 3 Apr, 00:00 -1 hour (DST end) Sun, 11 Sep, 00:00 +1 hour (DST start) 2023 Sun, 2 Apr, 00:00 -1 hour (DST end) Sun, 3 Sep, 00:00 +1 hour (DST start) 2024 Sun, 7 Apr, 00:00 -1 hour (DST end) Sun, 8 Sep, 00:00 +1 hour (DST start) 2025 Sun, 6 Apr, 00:00 -1 hour (DST end) Sun, 7 Sep, 00:00 +1 hour (DST start) 2026 Sun, 5 Apr, 00:00 -1 hour (DST end) Sun, 6 Sep, 00:00 +1 hour (DST start) Descarga de Responsabilidad: Este mensaje contiene información confidencial y esta dirigido solamente al remitente especificado. Si usted no es el destinatario no debe tener acceso, distribuir ni copiar este e-mail. Notifique por favor al remitente inmediatamente si usted ha recibido este mensaje por error y eliminelo de su sistema. La transmisión del e-mail no se puede garantizar que sea segura, sin errores o como que la información podría ser interceptada, alterada, perdida, destruida, llegar atrasado, incompleto o contener virus, por lo tanto el remitente no acepta la responsabilidad por ningunos de los errores u omisiones en el contenido de este mensaje, que se presentan como resultado de la transmisión del e-mail. Si la verificación se requiere, por favor solicite una versión impresa. Disclaimer: This message contains confidential information and is intended only for recipient specified. If you are not recipient you should not disseminate, distribute or copy this e-mail. Please notify to sender immediately if you have received this message by mistake and delete this from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The receptor therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required, please request a hard-copy version.

2 2

Comments
by Arthur David Olson April 24, 2023

April 24, 2023

Fun fact: the time zone database is 80% comments by volume. @dashdashado

7 8

Mexico timezones
by Var Nazari April 10, 2023

April 10, 2023

Hello, Mexico has recently abolished daylight savings except for where they border with the United States. I believe the timezone database is now inaccurate because it should not be showing CDT for most of the country any longer and should be CST instead. It seems like this was addressed in release notes for the tzdb version 2022f and 2022g but I'm not sure that the correct changes were applied. Could you verify/explain why the timezones in Mexico are still recorded as CDT? Is this a mistake? Thank you

3 5

Changing 24:00 to 0:00 where possible
by Jacob Pratt April 5, 2023

April 5, 2023

While writing a parser for tzdb files, I noticed that some rules are for a given date at 24:00, rather than the following day at 0:00. While in some cases this is unavoidable (Egypt), in others there is no reason this is necessary (Belize). I think it would be reasonable to change 24:00 to 0:00 where possible, incrementing the day, day of week, and month as appropriate. This would reduce the need for special casing values to those that have a technical reason. Jacob Pratt

8 12

Error in the "America/Santiago" timezone for one week of September 2022
by Javier Ayala March 31, 2023

March 31, 2023

Hello, There is an error in the 'America/Santiago' timezone. The week between September 4th, 2022 and September 10th, 2022 should have the offset of -4.0, but it currently shows -3.0. This error occurred due to the 2022 Chilean national plebiscite <https://en.wikipedia.org/wiki/2022_Chilean_national_plebiscite>, which caused the government to postpone the scheduled time change by one week, from September 3rd to September 10th. Sources: - Decree in Chile's Official Gazette: https://www.diariooficial.interior.gob.cl/publicaciones/2022/08/13/43327/01… - News published in Chile's government website: https://www.gob.cl/noticias/ministerio-del-interior-informa-respecto-al-cam… Greetings, Javier Ayala

2 1

(no subject)
by Jack Bakaev March 29, 2023

March 29, 2023

Hello, Lebanon decided to postpone the DST till end of April instead of march 25-26 TZ complied then the cabinet of Ministers in Lebanon decided yesterday March 27 to revert to DST during the night of March 29-30. please do not revert Lebanon DST back to March 25-26! this will cause problems for those who who already complied with the postponement please revert to DST during the night of March 29-30. Jack Bakaev Internet Society - Lebanon Chapter Chapter Secretary

2 1

Re: [tz] [PROPOSED 2/2] Fix comments on Lebanon this week
by Paige Tummons March 29, 2023

March 29, 2023

Hi Paul, I'm reaching out regarding your request for comments<https://mm.icann.org/pipermail/tz/2023-March/032833.html> on the proposal to revert back to 2023a instead of updating 2023c to reflect the Lebanon DST change of 30 March. I've been working closely with medical centers in Lebanon to ensure that their healthcare systems are in continuous legal compliance with the government directives. We have been in close communication with Lebanese government authorities who legally consider the spring forward event to be on 30 March (with the jump being from 11:59:59 PM on 29 March to 01:00:00 AM on 30 March). We are strongly urging you to reflect this update in the 2023c file, to avoid the published tzdata file being in direct conflict with the government directive of the spring DST event in Lebanon happening on 30 March. The Prime Minister met with the cabinet yesterday, and together they agreed that Lebanon DST happens on the 30th of March. No government authorities consider the 26 March 2023 event to be the "true" DST time for Lebanon. Thanks, Paige Tummons

3 2

[tz-announce] 2023c release of tz code and data available
by Paul Eggert via tz-announce March 28, 2023

March 28, 2023

The 2023c release of the tz code and data is available. This release's code and data are identical to 2023a. In other words, this release reverts all changes made in 2023b other than commentary, as that appears to be the best of a bad set of short-notice choices for modeling this week's daylight saving chaos in Lebanon. (Thanks to Rany Hany for the heads-up about the government's announcement this week.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2023c.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2023c.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2023c.tar.lz The following convenience links are also available, although they may point to the previous release until the relevant caches are refreshed: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit ddb8cf09d54ecc486ed6665edcdd642abccd4eef dated 2023-03-28 12:42:14 -0700 and tagged '2023c' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: fa18bae9c0e7c061bc9d5f5f2eb9967f0e4ddb2baafdee9887fa30cd0c60f4aa6f21eacffb17df0d59d26ff54d08c5dcefa98159309eba497e86443624913a82 tzcode2023c.tar.gz 608bd286ebcbd0004cfdc1da183273f08aff61f90c8867661154453d77a05d421e4c46ad6d066a1fe2e87d5c82ec0f1c0224667a3b35f3180a3eb7f6ff84cbf5 tzdata2023c.tar.gz b59dbfc598b98f325797ff587bd2e8b27aadc52924eeb0b26cd18cdaca56224c436a20950bc73de9b9b46e98d640a24d8cb797a8f49ada15ea2f42a70a6efe22 tzdb-2023c.tar.lz Here are GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmQjQ8MACgkQ7ZfpDmKq fjTp4BAAvitWlH49WQ+Cfs//1bBy7ifW1I5PNXSZFIDSNsZUGhrXOkZ/b6l3jAEF Z76GL7PQb5d/QHdKAIYeDheGnGf/8Wh4PFGzBkiyZgEdeZk6QLtE1n71Fu1x7gca IQOmVTzwVAf9f+fbizsaTarqg30TnPzUsuHiljInOaV8GkTt0VUkIZ5LeH09kdpY Rq6BIiehGikkBLyvCpyCTGZ4H8IKgR0GMkIHWQwj0mw/WROnT+xAfzTUrtD7zJK2 5+Ek2kj0UDB9DbprIkCZyh56W1OZ4m5OuAd9wHdx1ZOPfE6jq0lm+2B2kX4759mQ U66wyATu1qqqlc/2HUe464SWCyNTEDGbCCygfryInKd9Y+QORhK9yOsDfskVcGgX qTE2U20YzMqHP34fgTUsOC+mQ9e+qR1CvnCGAv3y1wpUIj1r9Opq7cI1uCvVE6xn nJhU1oE+z4HjhT2TZSS+gVM8D6p+z096sOkRnFg+mIh7XzSYYSFRojcGLnSAkg+o K68yPfXPu0subUGi5dH1XLQQYM0v0sqCATu5jKwU4YyyHoUuWDi9mooReAkSaj+y KON+VuYMRZZfJqzdc0HcXUsqlY/nK6/INRbtgvEKlMRLBn5oGbWIRnlyQvJA814v fsaewl80tRZAtXs/hwHrSGX1vxMkMaaDk5frG9BG/EkupBZa/rk= =fwRN -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmQjQ8MACgkQ7ZfpDmKq fjScAg/+LKVw3MFKXvXhDAJX9FPL+ZtvFc+XCwkAxylFA8rrLYjNTo+X7vdyu/AV 1YSkQFqPrPJrVMlffRm/NaQI59vOhkIQZ4Ingd0IFzfHIJMSMVU1C359mpUnxgce XLLUA12+Mjo3SEO/QYOZLhkpvzoJ2loPdgAUtraysunZdgYVdOubd8EpbWtZ/d9u cdKJriVWaHwcmEPXmZOcAhjTA2immhIrAd4G1FzuHFJNjdjIzJyXzxATWEk3mQ0z ZOQcpWGzf50OL9Atri4e8Nm4mXjguQHRebfYv8QVHAvxcdjGFc5yqvVrwGaNLGtV oadxHA3J/hmWS7mg7/pYDKabTNeoXrXWEzY8VXRbPnfvtbUXh9g4t9JDlgocHpQQ wAC3Hb/mvMFON68aCPWQeHxcHXOrAm2KHlGblJA9iI364S6v3iK7gd16lzZSbuTy G8jAt7YUilZxyIIV0GVMjQD9oG6bVm6ApccVVIBPHqlW1J09ON0koWRiNGqdbr8F BTh3ORBCo0qU+BvYF6mL9SCIrbGUvr4NdwY9aKaB04HPZz244fD2kLPt1z5v+7K6 cQrhdVQ6CqejhlJXRm4cQdeEzJhgxw+cFc256e8WpoofVu5rDws2d2KQZkqHGiFH A5jSKg2PWfZcqPoTdRg19DlUUdDBH8xybXzK5ExjHdDDO7KInGU= =XC0E -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmQjQ8QACgkQ7ZfpDmKq fjS96g//dxNELnczZASWUk7n+EJ5EbMjamjOOAde6r/Mpy/71DLg0AatISKt+Ph+ 7lAVzQRip6o4mZNZb9PZ6yP3r1rYKUymaOahtiwv5oC2lSmm2jCMRlFslHJ/feQc czOfCfd7ggpmg95Iqx81WYfc2lSbXzNArpvqBEjApqtkOLbpJ7A7s2JFn7o3lnD2 E1gMeiIbM4doq2Dfqzc3sJ2kyn/zmsA2g/HO64DZ9RUiDJlbOAZctIAfDiSkHE8q MTdSIVlKrOXDzmzvN1YMXyIPbo4ZaFCjvSZ5xbEpu8nf1IrLq0WqkU41T+4cq3zD Vq0NHrADU49npWh1qn/PTJunln6I6BHIXzyDAAZL+Ij1lcplRh/ZdszZBxU267Qx 6rvEqeea1jQPEKS2/x9aMSWk4mwooB1pYHjnpgS+ZP1CLHtrWVtf5zU4Z2sODWBd p1otOWWgR1nq7b4qc0OZwwVzuJN8rtptEf0PuxgKZnLLoVmgEpU5WxA5FjhTsJmm 1nbv676DfIN31NOfSGcP12Lcp2KjZ2Cfj++zmQruTlZcjpWYEJiRjiecqELBWo7S jw96jrEUQi6mVn6jhzV0Sxdiig9M0hmzMj0bcx2BvldbUFCbZscAproR9fHeqpZM Q4F6QphFyP5Y3kBKARZZ3HmM6Kc5ZWkG6WzLeTkTdcxqHZLrp8c= =YTzD -----END PGP SIGNATURE-----

1 0

[PROPOSED 1/2] Adjust attribution at Jad Baz’s request
by Paul Eggert March 28, 2023

March 28, 2023

--- NEWS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/NEWS b/NEWS index fe0e809..f400425 100644 --- a/NEWS +++ b/NEWS @@ -5,7 +5,7 @@ Unreleased, experimental changes Changes to past and future timestamps Model Lebanon's DST chaos by reverting data to tzdb 2023a. - (Thanks to Jad Baz for the heads-up.) + (Thanks to Rany Hany for the heads-up.) Release 2023b - 2023-03-23 19:50:38 -0700 -- 2.39.2

8 26

Policy Suggestion: Minimum time period betwen releases
by Howard Hinnant March 28, 2023

March 28, 2023

Recent events have brought to my attention the need to put a damper on chaos caused by poor planning. When governments give little notice to changes in time zone rules, this is not a problem that this group can fix, or should even try. I propose a minimum period of 30 days between successive IANA tz database releases. The train leaves the station no more frequently than once every 30 days (and will probably be less frequent). Whatever information is solid before the release date makes it on the train. Otherwise it can wait another 30 days (at least). My recommendation is in part based on this common statement: Poor planning on your part does not constitute an emergency on my part https://www.incirlik.af.mil/News/Commentaries/Display/Article/303134/poor-p… This week’s chaos isn’t unusual. In fact it is normal, especially for some countries. If they can’t be bothered to make a plan in advance and stick with it, I don’t see why this group of volunteers needs to compensate for that. Let the politicians lie in the beds they make. Howard

11 16

Reversal of timezone database file 2023b
by Roy Saad March 28, 2023

March 28, 2023

Dear Coordinator, The Lebanese government has reversed the decision to delay the shift to daylight savings time by a month (As per the articles below). Kindly update the time zone database to reverse the changes made in 2023b. (Sorry for the inconvenience created by incompetent public servants) https://www.bbc.com/news/world-middle-east-65090888 https://news.sky.com/story/lebanon-time-row-government-reverses-controversi… https://www.washingtonpost.com/world/2023/03/27/lebanon-daylight-saving-tim… Thank you and best regards, ROY SAAD Partner & Strategic IT Advisor 9th Fl., Confidence Centre, st. 15 , Sin El Fil, Metn 27076117, Lebanon T: +961 1 493 503 F: +961 1 489 172 M: +961 3 518230 www.trisq.com

1 0

Summer Time Zone in Lebanon
by Yvonne Sleiman March 28, 2023

March 28, 2023

Dear Sir in IANA, I would like to inform you that exceptionally, this year, we have done a postpone for applying the summer time zone in Beirut-Lebanon, In fact we used to do the transition from Winter time to daylight saving time at 1st hour of last Sunday in March, but this year exceptionally, and based on the Ministerial Cabinet decision, we postponed this transition to be applied at the 1st hour of Thursday March 30th, 2023. Kindly, be informed and take this decision in consideration. Best Regards [cid:910c6b6e-dad2-49d3-a352-02b429054397] Yvonne SLEIMAN Head of International Relations and Maintenance services Ministry of Telecommunications-Lebanon Tel: +961 1 979 122 - 123 Fax: +961 1 979 148 - 173 e-mail: ysleiman(a)mpt.gov.lb<mailto:ysleiman@mpt.gov.lb>

1 0

Proposal to revert 2023b's Lebanon data changes
by Ghassan Geara March 28, 2023

March 28, 2023

Dear Sir/Madam at IANA, Please note that the *Prime Minister *(Najib Mikati) of Lebanon/Beirut has reverted back his previous decision (of delaying the DST change until April 2023) *and decided yesterday to apply the summer DST time as of Wednesday March 29th at midnight. *(which equals to the night of March 29-30) Hereby the URL: https://www.al-monitor.com/originals/2023/03/lebanon-pm-reverses-daylight-s… Therefore we appreciate your immediate action on this matter. Best regards, Ghassan Geara ________________________________________ *Ghassan GearaTechnology Consultant & Advisor* Deek El Mehdi - North Metn - Lebanon Mobile: +961 3 93 43 96 Email: ghassan.geara(a)gmail.com LinkedIn: linkedin.com/in/ghassangeara

1 0

Re: [tz] Proposal to revert 2023b's Lebanon data changes
by Ahmad SOLH March 28, 2023

March 28, 2023

Dear, We understand that you may have received numerous emails regarding the recent Lebanon daylight saving and unplanned government decisions. As business owners and professionals, we respectfully request that you consider reverting to the previous summer time settings, especially since the government has withdrawn their decision effective 30th of March. Continuing with the newly implemented changes may negatively impact our businesses and cause us to fall out of sync with the rest of the world. We sincerely apologize on behalf of our government and believe that the actions of our leaders should not have an adverse effect on the people. Thank you, Regards, Ahmad SOLH Managing Director [cid:em15232572-152b-45b6-84f4-be0601b0fbc8@5c84fd39.com] M (CA) : +1-514-400 2490 | M (DxB) : +971-56-157 7898 | M (LB) : +961-3-414 664 CA: 292F Dalehurst Dr, Nepean, K2G 4E4, ON, Canada UAE: 2708, Sama Tower, World Trade Center, Dubai, UAE --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Disclaimer: This email may contain confidential information intended for the person or organization to which it is addressed. If you are not the intended recipient(s), please note that disclosing, copying, distributing or using this information is prohibited.

1 0

Apple pushing out 2023b
by Jad Baz March 28, 2023

March 28, 2023

It seems Apple is pushing out 2023b A survey on a Lebanese Telegram group shows that iOS users are receiving a notification to restart their devices to apply timezone changes This seems to be an incrmental rollout, however, as not all users have reported getting a notification Some MacBook users have also reported receiving a similar notification I checked with both iOS and MacBook users asking them to restart their laptop, set the date/time to April 20th at 23:59 and within a minute, it sprung forward to April 21st at 01:00 So this is undoubtedly 2023b and nothing else

1 0

Thank you!
by Fred Gleason March 28, 2023

March 28, 2023

As someone who mostly just _uses_ the TZ database to support various projects, I’d like to take a short break in our current Mideast Moment to express my gratitude to all of those volunteers who work to keep this oft-overlooked but critical bit of IT infrastructure accurate and functional. This includes both those who work on the code and data directly as well as the researchers and others “on the ground” who keep this group informed in the midst of sometimes chaotic and fast-moving situations. I greatly appreciate the time, effort and professionalism that all of you consistently bring to this task. Thank you! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | There's never time to do it right, but there's always time to do | | it over. | | | | -- Meskimen's Law | |---------------------------------------------------------------------|

3 2

Another Timezone update for Lebanon
by timings.06-flecks＠icloud.com March 27, 2023

March 27, 2023

1 0

Proposal to revert 2023b’s Lebanon data changes
by Paul Eggert March 27, 2023

March 27, 2023

We need a new release soon to address the time zone chaos in Lebanon. One option is to revert 2023b's data and go back to 2023a as I suggested earlier. Another is to record the chaos in more detail in the data. The attached proposed patch (which I installed into the developmental repository on GitHub) takes the former approach, as I expect the latter would cause more problems than it would cure. This follows a similar (although not identical) precedent in Rio de Janeiro in 1993. In short, the patch would make 2023c identical to 2023a except for comments, which do not count as part of the data. It is a confusing and controversial situation. Comments welcome. In the meantime I again suggest to downstream distributors to stick with 2023a and avoid 2023b.

7 9

Lebanon will not spring forward this weekend
by Paul Eggert March 27, 2023

March 27, 2023

On 3/23/23 09:42, Saadallah Itani wrote: > I had to send you the below as I am not subscribed to the list. I'll quote the rest of your message below so list subscribers see it. Thank you for the info about Lebanon deciding today to not change its clocks this weekend. Ouch, this is very short notice. Since the March 25 transition was scheduled for 24:00 (i.e., midnight between March 25 and March 26) I assume this means the spring forward transition is will occur midnight between April 20 and April 21. I created the attached proposed patch to record this. Please let me know if this interpretation sounds correct to you. We'll need a new tzdb release soon, as tzdb 2023a becomes wrong around 51 hours from now. >> On 23 Mar 2023, at 6:26 PM, Saadallah Itani <sitani(a)aub.edu.lb> wrote: >> >> Hello, >> >> Lebanon too announced today delay of Spring forward from March 25 to April 20. >> >> preview.jpeg >> 960008904374 >> <https://imagescdn.mtv.com.lb/articles/960008904374.jpg?width=2000&quality=75> >> JPEG Image · 19 KB >> <https://imagescdn.mtv.com.lb/articles/960008904374.jpg?width=2000&quality=75> >> >> <https://imagescdn.mtv.com.lb/articles/960008904374.jpg?width=2000&quality=75> >> >> >> Regards, >> Saad >> Ext. 2229 >> >> Sent from my iPhone

2 3

Re: [tz] tz Digest, Vol 138, Issue 71
by Rich Armstrong March 27, 2023

March 27, 2023

Though this list usually doesn't include discussion of the time-zone-rule data that Microsoft maintains in the Windows registry, it seems worth considering how to ensure the two repositories of time-zone rules might be kept in sync—not to mention IATA's repository. Thoughts and opinions from any MS representatives would be welcome. (Incidentally, I was born at 11:50 PM at a place and time when hospitals recorded births on standard time even though the general population observed DST. Consequently, I reserve the right to celebrate my birthday on the 12th and/or 13th of July.) ________________________________ From: tz <tz-bounces(a)iana.org> on behalf of tz-request(a)iana.org <tz-request(a)iana.org> Sent: Monday, March 27, 2023 1:29 PM To: tz(a)iana.org <tz(a)iana.org> Subject: tz Digest, Vol 138, Issue 71 Send tz mailing list submissions to tz(a)iana.org To subscribe or unsubscribe via the World Wide Web, visit https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.o… or, via email, send a message with subject or body 'help' to tz-request(a)iana.org You can reach the person managing the list at tz-owner(a)iana.org When replying, please edit your Subject line so it is more specific than "Re: Contents of tz digest..."

1 0

Urgent | Palestine Timezone "Asia/Gaza | Asia/Hebron" Daylight Changed unitl 29/04/2023
by Rifat Maswadeh March 27, 2023

March 27, 2023

Dear Sir, I'm Rifat From Palestine, Yesterday 25/03/2023 at 2:00 AM time changed "Daylight" +1 and set +3 GMT , This changed not updated in last Palestinian government decision about change daylight time in coming 3 years (2023,2024,2025) as follows : *29/04/2023 * [image: image.png] Thanks ! - attached

2 1

(no subject)
by Andrea Singletary March 27, 2023

March 27, 2023

Will 2023c have Asia/Beirut starting DST this year on March 30? What does this mean for future years? Wish the cabinet would've clarified that while they were on the subject, as Spring Forward intersects with Ramadan for the next few years... -- Sent from my pocket-sized infinite improbability generator

4 5

Lebanon reverse summertime delay
by Hagop Jamkojian March 27, 2023

March 27, 2023

Hi there, Just wanted to let you know that the Lebanese prime minister has decided to reverse the decision again https://www.bbc.com/news/world-middle-east-65090888 effective Wednesday night 😕 Timezone DB (https://github.com/eggert/tz) is still not updated to show this change, so wanted to give you a heads up. Best regards, Hagop Jamkojian

1 0

Lebanese Time Zone
by S J March 27, 2023

March 27, 2023

Hello, Your recent changes to Lebanon's adherence to DST is wrong: "This year Lebanon springs forward April 20/21 not March 25/26. (Thanks to Saadallah Itani.)" https://data.iana.org/time-zones/tzdb/NEWS The government of Lebanon did not issue a law decree stating this change and proper legal procedures were not followed. This led to civil action locally where all respected media and groups are not abiding by this decision, taken without any proper legal procedures. Please correct the change on your end to avoid adding to the massive confusion. All devices have already updated to DST, so your change is only adding to the confusion. Thank you for your understanding. I do not give the right to use my name, email or any other identifying information on any public communications or messages or updates.

2 1

Lebanon Resumes DST on March 29/30
by Bassel Shurbaji March 27, 2023

March 27, 2023

Hello, I thought I should let you know that the government of Lebanon announced that it will resume *DST* on* March 29/30* instead of* April 20/21* as per your latest *Release 2023b*. https://twitter.com/MTVLebanonNews/status/1640312857890832389 https://twitter.com/ALJADEEDNEWS/status/1640313313790681088 Best, Bassel Shurbaji

1 2

Re: [tz] Fw:Time Zone Iran
by Paul Eggert March 27, 2023

March 27, 2023

On 2023-03-26 23:39, Patrick.Stergonschegg(a)orf.at wrote: > Hello, > > > I just noticed that the Windows time zone for "UTC +03:30 Tehran" is probably being computed incorrectly. > > > It seems that DST +1 is being added, although Iranian Government announced that they will not switch to DST anymore, beginning in 2023. > > > Official IR News Agency announcement: http://irna.ir/xjJ3TT > > Current Time: https://time.ir > > > I assume that Microsoft imports IANA time zone data: http://bit.ly/3ZmGzTE > > > In the file tzdata2023b\asia on line 1625 it says: > > 3:30 Iran +0330/+0430 > > > I assume the line should be changed and a new line should be added, e.g.: > > 3:30 Iran +0330/+0430 2022 > > 3:30 - +0330 I don't see a need for such a change, as the "Iran" rules end this way: Rule Iran 2021 2022 - Mar 21 24:00 1:00 - Rule Iran 2021 2022 - Sep 21 24:00 0 - The shell command 'zdump -i -c 2021,2030 Asia/Tehran' outputs this: TZ="Asia/Tehran" - - +0330 2021-03-22 01 +0430 1 2021-09-21 23 +0330 2022-03-22 01 +0430 1 2022-09-21 23 +0330 which looks OK: it stops after 2022. If your MS-Windows host disagrees, perhaps you need to update its tables. I don't know how that works, though. > > More ressources: > > http://bit.ly/3lQC9qp > > https://www.timeanddate.com/worldclock/iran > > > I am looking forward to any feedback. > > > Thanks a lot, > Patrick > >

2 1

Lebanon's Cabinet Reverses Decision of DST Delay
by Patrick March 27, 2023

March 27, 2023

Hello IANA, This is to keep you updated that Lebanon has reverted its DST shift decision of the 23. https://www.reuters.com/world/middle-east/lebanons-cabinet-reverses-decisio… Thank you! Yours, --- Patrick Louis

1 0

Re: [tz] Lebanon will not spring forward this weekend
by Saadallah Itani March 27, 2023

March 27, 2023

Cancellation of DST postpone - official announcmenet Regards, Saad Ext. 2229 Sent from my iPhone > On 27 Mar 2023, at 1:30 PM, Saadallah Itani <sitani(a)aub.edu.lb> wrote: > > Dear Paul, > > Lebanese government announced to revert back the DST (March) timing and not to postpone to April on the evening of Wednesday at 23:59 > > Source: http://mtv.com.lb/News/1353208 > > > Please create a new db file. > > Thank you > > Regards, > Saad > Ext. 2229 > > Sent from my iPhone > >> On 24 Mar 2023, at 12:43 AM, Paul Eggert <eggert(a)cs.ucla.edu> wrote: >> On 3/23/23 13:22, Saadallah Itani wrote: >> >>> I hope Linux Vendors pull the new tzdb changes soon. >> >> We first have to publish tzdb 2023b with the patch for Lebanon <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.…>, which I hope to do quite soon. >> >> Unfortunately, many GNU/Linux and other downstream suppliers take some time (a week or more) to test changes before they release data to their users. So unless you're using one of the smaller, faster-moving distros like Alpine Linux you'll likely be out of luck. >> >> People in Lebanon can work around the problem temporarily with an approximation like TZ='EET-2EEST,M4.3.5/0,M10.5.0/0' (this is good for predicted timestamps from April 15, 2022 up to but not including March 31, 2024). If your system doesn't support POSIX TZ strings (many cell phones are like this), you can instead use an approximation like TZ='Africa/Tripoli' (good for predicted timestamps from March 27, 2022 up to April 21 of this year).

1 0

Lebanon DST change reverted
by Rany Hany March 27, 2023

March 27, 2023

Greetings, The DST change for Lebanon that was adopted in 2023b should be reverted 48 hours from now. The cabinet met today and rolled it back. The Council of Ministers decided to adopt daylight saving time once again starting from Wednesday night (needs details on exactly when "Wednesday night" is, I presume Thursday). Sources: * https://www.lbcgroup.tv/news/breaking-news/694239/%D9%85%D8%B9%D9%84%D9%88%… * https://www.mtv.com.lb/News/%D9%85%D8%A8%D8%A7%D8%B4%D8%B1/1353208/%D9%85%D…

1 1

Re: [tz] Lebanon will not spring forward this weekend
by Saadallah Itani March 27, 2023

March 27, 2023

Dear Paul, Lebanese government announced to revert back the DST (March) timing and not to postpone to April on the evening of Wednesday at 23:59 Source: http://mtv.com.lb/News/1353208 Please create a new db file. Thank you Regards, Saad Ext. 2229 Sent from my iPhone > On 24 Mar 2023, at 12:43 AM, Paul Eggert <eggert(a)cs.ucla.edu> wrote: > On 3/23/23 13:22, Saadallah Itani wrote: > >> I hope Linux Vendors pull the new tzdb changes soon. > > We first have to publish tzdb 2023b with the patch for Lebanon <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.…>, which I hope to do quite soon. > > Unfortunately, many GNU/Linux and other downstream suppliers take some time (a week or more) to test changes before they release data to their users. So unless you're using one of the smaller, faster-moving distros like Alpine Linux you'll likely be out of luck. > > People in Lebanon can work around the problem temporarily with an approximation like TZ='EET-2EEST,M4.3.5/0,M10.5.0/0' (this is good for predicted timestamps from April 15, 2022 up to but not including March 31, 2024). If your system doesn't support POSIX TZ strings (many cell phones are like this), you can instead use an approximation like TZ='Africa/Tripoli' (good for predicted timestamps from March 27, 2022 up to April 21 of this year).

1 0

Lebanon to go back to DST midnight Wednesday March 29th
by Jad Baz March 27, 2023

March 27, 2023

Lebanon to go back to DST midnight Wednesday March 29th https://twitter.com/ALJADEEDNEWS/status/1640313313790681088?t=G_VQcAnq10PSY… https://twitter.com/LBCI_NEWS/status/1640312096972742656?s=19

1 0

Lebanon DST change internally disputed
by Jad Baz March 26, 2023

March 26, 2023

Lebanon is going through many internal disputes surrounding the latest decision to delay DST Many institutions are refusing to comply with the change and are going to adopt regular DST on Sunday Mar 26th Those institutions include but are not limited to: - News agencies - Religious organizations - Schools, universities, etc... The refusal is mainly centered the legality of that decision and, obviously, the technical chaos it will create because of its short notice Moreover, as some of the below articles mention, this is also causing sectarian strife All of these concerns are important to bring to light in view of IANA's procedures for updating timezone data: If you would ask today "what the average person on the street would think the time actually is", it's not at all clear what the answer would be Below are some links about these latest developments: https://www.cnn.com/2023/03/25/middleeast/lebanon-daylight-savings-intl/ind… https://www.lbcgroup.tv/news/lebanon-news/693963/lbci-refuses-to-comply-wit… https://www.lbcgroup.tv/news/news-bulletin-reports/693989/lebanese-patriarc… http://www.mtv.com.lb/en/news/local/1352862/bkerke--we-are-committed-to-swi… http://www.mtv.com.lb/en/news/live_feed/1352804/mtv-will-not-comply-with-th… https://today.lorientlejour.com/article/1332635/postponement-of-daylight-sa…

10 20

Time Zone Iran
by Patrick.Stergonschegg＠orf.at March 26, 2023

March 26, 2023

Hello, I just noticed that the Windows time zone for "UTC +03:30 Tehran" is probably being computed incorrectly. It seems that DST +1 is being added, although Iranian Government announced that they will not switch to DST anymore, beginning in 2023. Official IR News Agency announcement: http://irna.ir/xjJ3TT Current Time: https://time.ir I assume that Microsoft imports IANA time zone data: http://bit.ly/3ZmGzTE In the file tzdata2023b\asia on line 1625 it says: 3:30 Iran +0330/+0430 I assume the line should be changed and a new line should be added, e.g.: 3:30 Iran +0330/+0430 2022 3:30 - +0330 More ressources: http://bit.ly/3lQC9qp https://www.timeanddate.com/worldclock/iran I am looking forward to any feedback. Thanks a lot, Patrick

1 0

Lebanon DST change update - central bank to use two timezones
by Jad Baz March 25, 2023

March 25, 2023

Lebanon's central bank said it would only adopt government decision (of postponing DST) for work shifts and schedules but would stick to regular DST time in its systems and transactions https://www.mtv.com.lb/news/%D9%85%D9%80%D9%80%D8%AD%D9%80%D9%80%D9%84%D9%8… https://twitter.com/BeirutCityGuide/status/1639653667694428161?s=20

1 0

[tz-announce] 2023b release of tz code and data available
by Paul Eggert via tz-announce March 24, 2023

March 24, 2023

The 2023b release of the tz code and data is available. It follows so closely on the 2023a release because Lebanon's government announced that Lebanon's spring-forward transition previously scheduled for the end of this week has been delayed until April 20. This release contains the following change: Briefly: Lebanon delays the start of DST this year. Changes to future timestamps This year Lebanon springs forward April 20/21 not March 25/26. (Thanks to Saadallah Itani.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2023b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2023b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2023b.tar.lz The following convenience links are also available, although they may point to the previous release until the relevant caches are refreshed: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit 71faa2a55db2c9f21f4099b58c28536673982e0a dated 2023-03-23 19:50:38 -0700 and tagged '2023b' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 94058ceabfdaa62eeff9be804a030f0eb95b4099b62fbb7e55557e8b934c8d883f488a3a6996331e24aebd147d66c19a73fb925a3dd929c630a9e11b51003b7f tzcode2023b.tar.gz 0f697b872ef02109d2098db12d0effc834b2ac5438921e0867f2c70987f305a47dc3eac720c344bb3757c902a7653109621e943564bdfbf00937077c311aa29b tzdata2023b.tar.gz 286ab1bf768dda48d4066d2477de0f3db9c26e55e26c1a4f33b450268255f28d57360bffe602a3bc29f8a281b7e0ff17880fe1d14914d6361f62abb7526e5081 tzdb-2023b.tar.lz Here are GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmQdELYACgkQ7ZfpDmKq fjQpIQ//eOaHIqWDFcotP/ntWHses+E1PaalrArGe6uoGJYR3Aql9GBIM/BrhBZH oiCeRxxsLLoU4ZoJdrEh3Q4q4a3g/j5NGL3oi1ktlwHz1dnJFd2UQ+XlK2mv2/Lb o+cwaM0RV8SZojClxXF/ditXgsJ+EGbSX7WYKX7XfCxdWwFw+ZZPPcYvmXvenFCl wtJWjgo11a3V7OpKk4kfX/EuoNoHTF7uOIr943Id96JFM0z7LET1zaoKzObMs0+l Afyi1Rl0bxO6rlPH+HRJb41cac1YXMcoRkz0rzvaZalEA4FYFYIsA4nbuVB1DGIW xzQLErGgBg9NFLSIQJmocS7V3T3KpSeIXAfUMN3XMUMVfOwv9Fm0ZdzgPEH3/Xhr h/6C1a18Q+xeicqaB7Hm+nybH51sFxajx9xoGcr+Ij+1ze1W4Rk7LnHC6+tsqQ/D N+P1fBEcb33C3/T8G2s+OWNMRInotcqAnZYUqLkFTmNbWEC1xdWdUZGxY+0PxDSX c7UGAgj7E9G4JS684AkcpVgIJUwz0XyQIZkJHudg7FyEjW7U7qIycXUwC+RCVtWb tnJX9TxzP01/kD3R3C8CALByCJW4OTlpwcETqACjUF6JBpAHHbFWGY1znBs/zsDa PSMozhoQ3moWHRBsW3PU7XBsxOf6kDMrqUxWTo1oKVv0Jy5xfO0= =UybO -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmQdELYACgkQ7ZfpDmKq fjQJpg//cdQED6jsk1BnqHOCL1/PPUxJsl1SmDlcAoO4o7Odt5AlTFq6P6zGzRze F+P1P6k9mD09IyiQC3m3wQaROoyAoaErPeuzwmoDT/rBVNRraSE0t8xy2jDytkne CH3f1TMYYqQOWpQnDxzMKByypkNCG9o0ryzhTMWRI9BNnLZqwRnyRFWPdLYM5O7/ DxFk3YbtoB9IoO2LR32dqYxrrKKb6cjr7exTGI+0WQNwQEK0HV/62bImDmparUei 8BZKc9fk41xNYJJxdew81pSAmRK6TMHPOG5cvs8KPLIb/lKfG21wJXL0wDr0U4wy L15riEQlkRckzG2IIV2OB5F+5MY7NWNHubuJ0YEBDJkPMQKfBPSkZM1xkvosiend 8BBgHPBH4HiZ9z/ZvrRXyIjOOpYuko9wyiqtRpqSp4OimB2RMV6VG8oSD+OG3YCj VhF2+KlZwLj9mG9sOeslDuBnp4h4eyCvVoILQNE0qYjeHGY4WTkqP/l29ZI2+rQW cfcOk8atl4ojmekmsLcoz3EnJLtDIgtLtchHTIKsDQgZnVNASnvpaZXU3l8T6fZf 0PitHf90Qj2WWkuiMkNBbS0q4D/CknH7pqy1TY8/IWQRrvPp9deLDEMs+TcSleOk 1HZ1bxgCL1lgqQGiqC66Ybyy794bG6g3CclFkSHGGB8UcC1hkg8= =o96Z -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmQdELgACgkQ7ZfpDmKq fjRyIhAAiuZfMpkCkyrVZycCouQsPeYtUPSeJpbaUHktBWZYxZ7JwCvLEFx9RC1+ Pz3Siiwes7Q0R0yuFCOr11oDfS9br22WOuvSYdaNacdxp8Xas8s5vKwj5ObJcu+a sYyrKMBlEf4nPiwZTXNaX5OW+kNJEFS9A+TS2vJ0Us3JzWrcfucBVnSwDqIkXWO5 99JXfqENH5OtxX5hbrGLCJ6g0A48tFgHWCXWIQ3NyCZQQzylLjQubXZHkcn9VVhP R1eesSskihJrNpUAaTS8eneZeJ9sdT7iulk+cgCI+uTMl+QOFtiEBxtF7Osj1faq xgguz7qIP2h47EIZDsBpKvyyOxL5MDsrGvbu/1zi6QzbBjIXR7UQ1s9OzZy+Zh+r Nxav3vYHXHpayFn7i6/BTEjLak4Jdr526DwyM9OAxiq9Bx4d6LAk3H14OHFKa6i8 6Nbp+4SjhuD+ycjyyU49SIdCYvakXgHHYHSnngXQzp9LO01cG4tHfnFadYN+l6Va iu+HqPBQqbieuKqqtC9Zvx0xSFxUQLnraVTERkaUFPNRPhxiezMStPCCAbAhceAc cXsfbhcrQrvd46L9Lm89+ywkNsrVw9e/j3yWsHTAxhqpyda6v/XRUV9LgqwSUego MKQT5q/XB7Zn7stC6Fj/XHzh4Ty4yLJ65SWjreXV1+C+fqijVA8= =BTwz -----END PGP SIGNATURE-----

1 0

Lebanon DST last minute postponed, IANA not informed!
by Jad Baz March 23, 2023

March 23, 2023

Dear timezone coordinators, My name is Jad Baz, I am a software engineer from Lebanon I just wanted to bring to your attention an issue concerning Lebanon's last minute cancellation of DST this Sunday (March 26th 2023) Lebanon, as part of the EEST timezone, is supposed to enter in DST this Sunday However, this was postponed due to Ramadan It was announced today (Thu March 23rd) by several news outlets that the Secretary General of the Council of Ministers decided to change postpone DST from this Sunday March 26th to April 21st Below, you will find a few links to news articles in English from trusted Lebanese news agencies: - https://www.lbcgroup.tv/news/lebanon-news/693669/lebanon-postpones-daylight… - https://www.mtv.com.lb/news/local/1352516/lebanon-postpones-daylight-saving… I checked the latest IANA updates from March 22nd and did not find mention of this latest development I think this decision was taken haphazardly without much regard for how this change will be propagated (as are most decisions in Lebanon, sadly...) I know my question is coming quite last minute But I'm wondering what needs to be done to save the situation as this is causing a lot of chaos (eg airlines) I looked at the procedures doc and initially thought that there must be some formal communication that needs to go out from government employees but it seems that "what the average person on street would think the time actually is" is enough So my questions are: - Are the above articles enough to make this change? Or is there any other data you need that I can help with? - Do you expect this might be amended by Sunday? If not, what's a more realistic estimate of a schedule? Thank you very much, Jad Baz

1 0

DST Change in Lebanon
by Rany Hany March 23, 2023

March 23, 2023

Hello, Lebanon has extended daylight savings time until April 20 2023 (exceptionally this year). It's so that people fasting this ramadan stop their fasting at 5PM instead of 6PM. Sources: - https://twitter.com/grandserail/status/1638874765954785280 - https://twitter.com/timourazhari/status/1638877448447115266 Best

1 0

Fwd: [tz-announce] 2023a release of tz code and data available
by Saadallah Itani March 23, 2023

March 23, 2023

1 0

Asia/Bangkok
by Chris Walton March 22, 2023

March 22, 2023

Paul, Sorry for the timing of this message; I know you are in the middle of trying to push out 2023a. At some point in the last few months the description of Asia/Bangkok in zone1970.tab changed from "Indochina (most areas)" to "north Vietnam". Is this really what you intended? -chris

2 1

[tz-announce] 2023a release of tz code and data available
by Paul Eggert via tz-announce March 22, 2023

March 22, 2023

The 2023a release of the tz code and data is available. This release contains the following changes: Briefly: Egypt now uses DST again, from April through October. This year Morocco springs forward April 23, not April 30. Palestine delays the start of DST this year. Much of Greenland still uses DST from 2024 on. America/Yellowknife now links to America/Edmonton. tzselect can now use current time to help infer timezone. The code now defaults to C99 or later. Fix use of C23 attributes. Changes to future timestamps Starting in 2023, Egypt will observe DST from April's last Friday through October's last Thursday. (Thanks to Ahmad ElDardiry.) Assume the transition times are 00:00 and 24:00, respectively. In 2023 Morocco's spring-forward transition after Ramadan will occur April 23, not April 30. (Thanks to Milamber.) Adjust predictions for future years accordingly. This affects predictions for 2023, 2031, 2038, and later years. This year Palestine will delay its spring forward from March 25 to April 29 due to Ramadan. (Thanks to Heba Hamad.) Make guesses for future Ramadans too. Much of Greenland, represented by America/Nuuk, will continue to observe DST using European Union rules. When combined with Greenland's decision not to change the clocks in fall 2023, America/Nuuk therefore changes from -03/-02 to -02/-01 effective 2023-10-29 at 01:00 UTC. (Thanks to Thomas M. Steenholdt.) This change from 2022g doesn't affect timestamps until 2024-03-30, and doesn't affect tm_isdst until 2023-03-25. Changes to past timestamps America/Yellowknife has changed from a Zone to a backward compatibility Link, as it no longer differs from America/Edmonton since 1970. (Thanks to Almaz Mingaleev.) This affects some pre-1948 timestamps. The old data are now in 'backzone'. Changes to past time zone abbreviations When observing Moscow time, Europe/Kirov and Europe/Volgograd now use the abbreviations MSK/MSD instead of numeric abbreviations, for consistency with other timezones observing Moscow time. Changes to code You can now tell tzselect local time, to simplify later choices. Select the 'time' option in its first prompt. You can now compile with -DTZNAME_MAXIMUM=N to limit time zone abbreviations to N bytes (default 255). The reference runtime library now rejects POSIX-style TZ strings that contain longer abbreviations, treating them as UTC. Previously the limit was platform dependent and abbreviations were silently truncated to 16 bytes even when the limit was greater than 16. The code by default is now designed for C99 or later. To build in a C89 environment, compile with -DPORT_TO_C89. To support C89 callers of the tzcode library, compile with -DSUPPORT_C89. The two new macros are transitional aids planned to be removed in a future version, when C99 or later will be required. The code now builds again on pre-C99 platforms, if you compile with -DPORT_TO_C89. This fixes a bug introduced in 2022f. On C23-compatible platforms tzcode no longer uses syntax like 'static [[noreturn]] void usage(void);'. Instead, it uses '[[noreturn]] static void usage(void);' as strict C23 requires. (Problem reported by Houge Langley.) The code's functions now constrain their arguments with the C 'restrict' keyword consistently with their documentation. This may allow future optimizations. zdump again builds standalone with ckdadd and without setenv, fixing a bug introduced in 2022g. (Problem reported by panic.) leapseconds.awk can now process a leap seconds file that never expires; this might be useful if leap seconds are discontinued. Changes to commentary tz-link.html has a new section "Coordinating with governments and distributors". (Thanks to Neil Fuller for some of the text.) To improve tzselect diagnostics, zone1970.tab's comments column is now limited to countries that have multiple timezones. Note that leap seconds are planned to be discontinued by 2035. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2023a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2023a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2023a.tar.lz The following convenience links are also available, although they may point to the previous release until the relevant caches are refreshed: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit f24b84a13556c12441dd55c323f9a8fd3b6fbbee dated 2023-03-22 12:39:33 -0700 and tagged '2023a' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: d45fc677a0a32ae807bf421faceff675565ee15e3ff42d3a4121df10e1f7855ac16b27fbc28bd365f93c57f40c5bdf19cde88546f7090cfab7676cac0a5516a4 tzcode2023a.tar.gz 10aadd6eba50f63f427399281065ba34cb474f6a854f8dc7a6f4f1343b1474a05f22b69b1e113ea67bb5f3f479253610a16b89d9dfa157bf0fde4c69aa3d6493 tzdata2023a.tar.gz 8e959f6cad84e9481ed5a6efcc8d7126d41fadfdc860715fea87fb15f7dcfdbc4c9d49828df2945ee9304dbdd3370c5b5048c62637bdd4f4962830ba101008bd tzdb-2023a.tar.lz Here are GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmQbXA8ACgkQ7ZfpDmKq fjSDXRAAjfD1GMYAFHDvXOlCCitgTsTjBBuPHPbrQ7gTWno9uX8bvss3aXCUslHv sfzCHMKhJqMXGLzSQQ5jEP/k4fOjNJyIQbVlrY9XljpdGeOdYa1E0zr95dIf4/ta NUY9XxzFnd3hwQuc6LY77MOv2Xyy/5RAGajD2DTpYTLjE0ffMFK371efs//GcLqe aCIWBdet1rJyih6CoyzfNvl6QHQOxZLSlE2E3DYu430fTi/UhmTcaATW8gRNulL5 kXamzD9l45/cGOx/jHP6CkJIqFTFV4W1/W/VyjIEgRE0KGbuQO3LV0avohjhmmwm hS6H6RJYfgeF+vwmo3unN+vUwPLhkPUiz2NO/Uf0n22AVQlUOrEP0XVXYW8aRd3H ewDrlvDCMkvmKqEb8k0jqbmjqTgeblKoqeS7gIShhVmrIli8oN4mguWg5WaeRWF/ l3uYtBXOg/DJMwENrB+4u0+PRWuR2T5OW/E4NvaKIu58qzozP7WEmlEwv9KWZB+z ffmNaVgXqSCz50K6gvhoDKLn5YBgpB9kXDd+YrcqPUAyD0sDWhBC2Hx9HHePOfQl dFB+ijja5HB8aZD/rX0iLrSwp/Ndt4l2QjXY9SMjTiWx4SgGGmGCANQqCDZGD31a C8bdEMH4qQeOPZ/NsPB6KaJsqALNroF07YeINu0YfWkw89ZF/r4= =mRAo -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmQbXA8ACgkQ7ZfpDmKq fjRngg/8D8E5sJIt412pmR7yIQYnsG44nSiELNpiewG+SF4DofW7quQDQEjDMdVn seLU9okE1/l+1SN6eibMJgvho/6HWkU9kWLzYCY29sljTVYqEu6vLo1IY1OJIkjC 9yieL33oLkN4LIeSMzR4QOCkRfusYNRYq3uryVtMu7R6HP2PgMlmmJf/imV192tj ONJXNA4Y30EvJ3lHuXMbr7fNg9hXSLjRy1NPKjp5OVZ3jZVXPljrC+egAfhLjZdQ uB5a3uGjAX+KjemCHwTmrrmmcUlaHxFxlfN5gX5cNIXuyrYtz0PAhy+MhBM5F9iY erYWg6EfBr7IfSyS1JcDZ1ypwZ66EpKxXfWZNm+HFA4dDdnWgvlM4n1OyKjw03Dq 4/agYr34cUDhfBUS57dtpZSibtdpbh8oiqxc+wXV3KZcHXVpX3XRyGTH1UVINfnF nXArC09JKUt7Tjol83TPH0jDXJAxabkgUDJHfpeQ5A8r3GNW1PQ/OF25ieRb+AFQ jWFbiEIxSXmUwnRc6wHiLX/gU0TT7vVMokN5erx9IGwrDEQAljuEJoj2bYFT/q9D 8jFA+48r/nK2r33+OBrz6aryoMNptquuMG0XR4aSr6KO3e622+vuF4nSN7hg2sAM /bMLSlzOGUEmOZ2D7hP5MDdWw5L0WQAjX7/8xKzdlMhqkx4Mc9Q= =OxWX -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmQbXBAACgkQ7ZfpDmKq fjQJaQ//aj78DFo7hiHX7VNnyEIKdddIApk6PKN6XkfCxVyXDxztE9w4Bf8LhYR2 hw0TFDtaIDpW0tb6OTQ/r/I2xMmeYKT52YPKL6KtKmc8tmzM4DiBT0CT/c//nxSl elxnuRI1wPbvP21XjuqbKBztN7ID1KC6YAs78045Cek+1K1lx5z9QcnYNLGIBwn3 EP4zi3qkMKQRKuT07ESQy4+y7hezPy9CPZMObmQ/v4nmUk0OIvbHGBK0TAc8D6kI Tsv1mAk4FHnbpbtpdXwfGDGpYfBs8giMHH6M+ZGdaT452hKrOwCgrvzsGlOxsxDc Ht4iASO78OEjdA/5cEscYYdoxOQCcTeDQEfWYx5bNfCFNvUKzrs79Qs1GaQ9riXW zdRBjW0sKbKZUoM9ZPjtYxRfh8PrZY9qDoZ4orF/39jl3SkBYkCC8IsKtEEVUYm/ ELH930IXmJ49sVdl+9ROGgqGUPcaVfouZf/+qf8d6HSEolOgrXe9FkB9E42RLBXw ETO/yL0MHPRiJU8U2agRV3AMiJoxM07ZvH54BgAsSXl1vr7xaCMqy5B38R7U/Tmj Sp7pqvtKhUcqyLHRi073GZmdV3pFhRsfAgiXTpRdNTAyJpN+y6jO9pZg6YYEfb+w kql/6Gp76ffGQU1j3OnvmVnmS22a34WiBZ0iYsKhrU/sym3Pk88= =SZ+n -----END PGP SIGNATURE-----

1 0

Summer Time in Palestine for 2023s year
by heba.hamad March 22, 2023

March 22, 2023

3 2

Re: [tz] [tzcode 2022g] Undeclared variable/typo in zdump.c
by Paul Eggert March 22, 2023

March 22, 2023

On 2023-03-22 02:55, panic wrote: > I contact you directly, because access to the mailing list is currently > very limited (new subscriber). Thanks, I'll include a copy of your email below, so that other subscribers of the tz mailing list can see it. > I try to cross-compile tzcode 2022g from GNU/Linux (NixOS) to Windows > using GCC 12.2.0 (x86_64-w64-mingw32) and get this compilation error: > >> In file included from zdump.c:14: >> zdump.c: In function 'zdump_tzalloc': >> zdump.c:264:38: error: 'initial_envptrs' undeclared (first use in this function); did you mean 'initial_nenvptrs'? >> 264 | if (ckd_add(&initial_nenvptrs, initial_envptrs, 1) >> | ^~~~~~~~~~~~~~~ >> private.h:414:51: note: in definition of macro 'ckd_add' >> 414 | # define ckd_add(r, a, b) __builtin_add_overflow(a, b, r) >> | ^ >> zdump.c:264:38: note: each undeclared identifier is reported only once for each function it appears in >> 264 | if (ckd_add(&initial_nenvptrs, initial_envptrs, 1) >> | ^~~~~~~~~~~~~~~ >> private.h:414:51: note: in definition of macro 'ckd_add' >> 414 | # define ckd_add(r, a, b) __builtin_add_overflow(a, b, r) >> | ^ >> make: *** [<builtin>: zdump.o] Error 1 > > I suspect `initial_envptrs` is a typo and should be `initial_nenvptrs`, > as the former does not occur anywhere else. > > Building natively for Linux works just fine. For cross-compilation, I > build additionally with > >> "CFLAGS+=-DHAVE_DIRECT_H" >> "CFLAGS+=-DHAVE_SETENV=0" >> "CFLAGS+=-DHAVE_SYMLINK=0" >> "CFLAGS+=-DRESERVE_STD_EXT_IDS" > > `-DHAVE_SETENV=0` selects the alternative path in `zdump_tzalloc` and in > combination with a recent GCC triggers error. Normally, `HAVE_SETENV=1` > and the code path is not compiled. Maybe the combination of a recent GCC > and > `-DHAVE_SETENV=0` is rarely tested and therefore the typo was not > discovered before. > > Cheers, > -- panic Thanks for the bug report. I've never built with that particular combination, and you exposed a couple of typos. I reproduced the problem artificially on GNU/Linux by building with "make CFLAGS='-DHAVE_SETENV=0'" and installed the attached patches. This fix should appear in the next release, which should be soon.

1 0

[PATCH] Pacify gcc -Wunused-parameter
by Paul Eggert March 22, 2023

March 22, 2023

* zdump.c (localtime_rz, tzfree): [! USE_LOCALTIME_RZ]: Mark unused args with ATTRIBUTE_MAYBE_UNUSED. Problem found when compiling with -DUSE_LTZ=0 on Fedora 37 with GCC 12.2.1 20221121 (Red Hat 12.2.1-4). --- zdump.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zdump.c b/zdump.c index 77ecb18..88bcd3a 100644 --- a/zdump.c +++ b/zdump.c @@ -228,7 +228,7 @@ localtime_r(time_t *tp, struct tm *tmp) # undef localtime_rz # define localtime_rz zdump_localtime_rz static struct tm * -localtime_rz(timezone_t rz, time_t *tp, struct tm *tmp) +localtime_rz(ATTRIBUTE_MAYBE_UNUSED timezone_t rz, time_t *tp, struct tm *tmp) { return localtime_r(tp, tmp); } @@ -304,7 +304,7 @@ tzalloc(char const *val) } static void -tzfree(timezone_t initial_environ) +tzfree(ATTRIBUTE_MAYBE_UNUSED timezone_t initial_environ) { # if !HAVE_SETENV environ = initial_environ; -- 2.39.2

1 0

Time Zone Database
by EL MAAYATI Afaf March 22, 2023

March 22, 2023

Dear Paul, I'm Afaf EL MAAYATI from National Telecommunications Regulatory Agency in Morocco. Actually, in the current version of Time Zone Database (https://www.iana.org/time-zones) for Africa region, and especially for Morocco, it’s mentionned that a program will be running to implement the transition dates. According to this program, the next transition dates (during 2023) are as below : - March 19, 2023 (switching to GMT). - April 30, 2023 (switching back to GMT+1). In fact, we will switch back to GMT+1, advancing 60 minutes, on Sunday, April 23 at 2:00 a.m (not on April 30). Please refer to the official annoncement, published by the Ministry of Digital Transition and Administration Reform: https://www.mmsp.gov.ma/fr/actualites/passage-%C3%A0-l%E2%80%99heure-gmt-%C… So, would you please update the program, in order to consider « April 23 at 2:00 a.m » (for switching back to GMT+1). Thank you in advance for your feedback and for your habitual support. Thank you. Best Regards, Afaf EL MAAYATI National Telecommunications Regulatory Agency Morocco [https://www.anrt.ma/images/ANRT-Signature.jpg] ________________________________ Ce message, son contenu et toutes les pièces jointes sont adressés à l'attention exclusive de leur (s) destinataire (s) et sont strictement confidentiels : ils relèvent de la correspondance privée. Toute publication, utilisation ou diffusion, même partielle, par des personnes autres que les destinataires est interdite et doit être autorisée par l'Agence Nationale de Règlementation des Télécommunications (ANRT, Royaume du Maroc). Si vous recevez ce message par erreur, nous vous prions de le détruire après en avoir informé son expéditeur sans délai. L’ANRT décline toute responsabilité pour toute altération, déformation ou falsification subi par le message et ses pièces jointes au cours de leur transmission. Retrouvez toutes les informations de l’ANRT sur son site Web à l’adresse suivante : http://www.anrt.ma. ________________________________ This message, its content and its attachments are intended for the exclusive use of the named addressee (s) and are strictly confidential. Any copy or other use of this information by persons or entities other than the intended recipient is prohibited and should be authorized by the National Agency of Telecommunications Regulation (ANRT, Morocco). If you have received this communication in error, please delete the material and notify the sender. The ANRT accepts no liability for any alteration, distortion or falsification that may occur during the transmission of this message. All information about ANRT can be found on our website at the following address http://www.anrt.ma. ________________________________ إن هذه الرسالة ومحتواها ومرفقاتها موجهة خصيصا للشخص المرسل إليه وتعتبر سرية وتصنف ضمن خانة المراسلات ذات طبيعة شخصية. ويمنع منعا كليا نشر أو استعمال أو بث، ولو بطريقة جزئية، لهذه الرسالة من طرف أشخاص غير المرسل إليهم ما لم يتم الترخيص بذلك من طرف الوكالة الوطنية لتقنين المواصلات (المملكة المغربية. في حالة ما إذا توصلتم هذه الرسالة عن طريق الخطأ، يرجى منكم العمل على إتلافها فورا بعد إخبار الشخص المرسل إليه بذلك. ولا تتحمل الوكالة الوطنية لتقنين المواصلات أي مسؤولية عن أي تحريف أو تغيير أو تزييف قد يلحق بمحتوى الرسالة أو بمرفقاتها خلال عملية الإرسال. للمزيد من المعلومات، يرجى الاطلاع على الموقع الإلكتروني للوكالة الوطنية لتقنين المواصلات : http://www.anrt.ma.

2 3

Maryland bill status
by Arthur David Olson March 21, 2023

March 21, 2023

Crossover day has come and gone in the Maryland state legislature; bills not passed by one of the two chambers by crossover face substantial hurdles in gaining approval. Neither the House-side nor the Senate-side bills shifting Maryland to permanent DST (with the potential for a short-notice shift) made it out of committee. Links to bill status below. My guess: the bill (it's actually the same bill, cross-filed) will be back next year.-( @dashdashado https://mgaleg.maryland.gov/mgawebsite/Legislation/Details/hb0165?ys=2023rs https://mgaleg.maryland.gov/mgawebsite/Legislation/Details/sb0268?ys=2023rs

1 0

Egypt Daylight Savings Times for 2023
by Mostafa Dahab March 21, 2023

March 21, 2023

Dears, This is to check if any package is available for Egypt (Africa/Cairo) with the below DST description. We couldn't find any on the web site, so we were also wondering about how to request a package. [cid:image001.png@01D957DC.84E5E1E0] BR, Mostafa Dahab

2 1

Egypt/Cairo timezone DST change
by Randy Sidhu March 21, 2023

March 21, 2023

Hello, The Egypt/Cairo timezone is implementing DST this upcoming April 28th. Has the tzdata file been updated to reflect this for the files available on this site: https://www.iana.org/time-zones tzdata2022g.tar.gz<https://data.iana.org/time-zones/releases/tzdata2022g.tar.gz> (429.4kb) Data Only Distribution >From looking at the latest data available I do not see the upcoming DST change implemented. Can you verify please. Thanks, Randy Sidhu

1 0

DST Change in Egypt
by Mina Samuel March 21, 2023

March 21, 2023

Dear Team, Seeking your support to publish an updated package which contains the new update for EGYPT DST as it will return back as mentioned on below links. Adjusting the clock - Egypt - Al-Ahram Weekly - Ahram Online<https://english.ahram.org.eg/NewsContent/50/1201/491316/AlAhram-Weekly/Egyp…> Egypt Reintroduces DST to Save Energy (timeanddate.com)<https://www.timeanddate.com/news/time/dst-egypt-2023.html> DST News - Egypt to return of Summer Time daylight saving time in 2023 (worldtimezone.com)<https://www.worldtimezone.com/dst_news/dst_news_egypt11.html> https://www.skynewsarabia.com/business/1601471-%D8%AA%D9%88%D9%82%D9%81-7-%… [cid:image001.png@01D95823.90EEF7A0] [http://mediabank.ericsson.net/internet-media/Email_logo_Ericsson.png]<http://www.ericsson.com/> Mina Samuel Service Delivery Manager Service Delivery Manager MMEA NEW S&R CU SSE mina.samuel(a)ericsson.com Ericsson Smart Village KM 28 6580,Sixth of October City Egypt ericsson.com<http://www.ericsson.com/> [http://mediabank.ericsson.net/internet-media/Email_Message.gif]<http://www.ericsson.com/current_campaign> Our commitment to Technology for Good<http://www.ericsson.com/thecompany/sustainability-corporateresponsibility> and Diversity and Inclusion<http://www.ericsson.com/thecompany/diversity-inclusion> contributes to positive change. Follow us on: Facebook<https://www.facebook.com/ericsson> LinkedIn<https://www.linkedin.com/company/ericsson> Twitter<https://twitter.com/Ericsson> Legal entity:ERICSSON EGYPT LTD. registration number 16630, registered office in . This communication is confidential. Our email terms: www.ericsson.com/en/legal/privacy/email-disclaimer<https://www.ericsson.com/en/legal/privacy/email-disclaimer>

2 2

Daylight Saving Time in Egypt
by Mahmoud Mohamed-Swailam, Vodafone March 19, 2023

March 19, 2023

Dears, The Egyptian government has announced that, the country will reintroduce Daylight Saving Time (DST) from April 28, 2023 as following. The New Egyptian DST Schedule Clocks will be set forward 1 hour: * Friday, April 28 at 00:00 (midnight), to 01:00 (1 am) local time<https://www.timeanddate.com/time/zone/egypt> on Friday, April 28, 2023. Clocks will be set back 1 hour: * Friday, October 27 at 00:00 (midnight), to 23:00 (11 pm) local time<https://www.timeanddate.com/time/zone/egypt> on Thursday, October 26, 2023. Seeking your support to share TZ packages contains the new update for Egypt DST. Please find the below reference link Egypt Reintroduces DST to Save Energy (timeanddate.com)<https://www.timeanddate.com/news/time/dst-egypt-2023.html> Thanks, [cid:image001.png@01D95A7F.32C359B0] Mahmoud Swailam NMS Tech. Lead Technology - Service Management Mobile: +2010-1900-2994 mahmoud.mohamed-swailam(a)vodafone.com<mailto:mahmoud.mohamed-swailam@vodafone.com> Smart Village-Vodafone-C3 Vodafone.eg Together we can

1 0

Extended winter time
by heba.hamad March 19, 2023

March 19, 2023

5 7

Announcement on changing of standard time for Greenland (Nanoq - ID nr.: 22820029)
by Jógvan Svabo Samuelsen March 16, 2023

March 16, 2023

2 2

How Time Zones Are Coordinated
by Kim Davies March 15, 2023

March 15, 2023

Yesterday we posted a short article that gives a primer on this project: https://www.icann.org/en/blogs/details/how-time-zones-are-coordinated-13-03… It is also being circulated to attendees to our major conference being held in Mexico this week. An objective in posting this is to better raise awareness with policy makers to plan time zone rule changes well in advance so that changes can be thoroughly disseminated. There are many government representatives from around the world at this Mexico meeting so hopefully this can contribute to spreading the word. kim

3 2

Re: [tz] Morocco : Ramdan Time Change 2021
by Paul Eggert March 15, 2023

March 15, 2023

On 3/19/21 3:15 AM, Semlali Naoufal wrote: > At the moment, we have no official government announcement to this effect. But, logically, the change to the GMT schedule should be made on the night of April 10-11, 2021 (last weekend before Ramadan). Yes, that's been the tzdb prediction too, ever since tzdb version 2018h (2018-12-23). For the record, here are tzdb's current predictions Morocco transitions during the next five years. Sun Apr 11 01:59:59 2021 UT = Sun Apr 11 02:59:59 2021 +01 Sun Apr 11 02:00:00 2021 UT = Sun Apr 11 02:00:00 2021 +00 Sun May 16 01:59:59 2021 UT = Sun May 16 01:59:59 2021 +00 Sun May 16 02:00:00 2021 UT = Sun May 16 03:00:00 2021 +01 Sun Mar 27 01:59:59 2022 UT = Sun Mar 27 02:59:59 2022 +01 Sun Mar 27 02:00:00 2022 UT = Sun Mar 27 02:00:00 2022 +00 Sun May 8 01:59:59 2022 UT = Sun May 8 01:59:59 2022 +00 Sun May 8 02:00:00 2022 UT = Sun May 8 03:00:00 2022 +01 Sun Mar 19 01:59:59 2023 UT = Sun Mar 19 02:59:59 2023 +01 Sun Mar 19 02:00:00 2023 UT = Sun Mar 19 02:00:00 2023 +00 Sun Apr 30 01:59:59 2023 UT = Sun Apr 30 01:59:59 2023 +00 Sun Apr 30 02:00:00 2023 UT = Sun Apr 30 03:00:00 2023 +01 Sun Mar 10 01:59:59 2024 UT = Sun Mar 10 02:59:59 2024 +01 Sun Mar 10 02:00:00 2024 UT = Sun Mar 10 02:00:00 2024 +00 Sun Apr 14 01:59:59 2024 UT = Sun Apr 14 01:59:59 2024 +00 Sun Apr 14 02:00:00 2024 UT = Sun Apr 14 03:00:00 2024 +01 Sun Feb 23 01:59:59 2025 UT = Sun Feb 23 02:59:59 2025 +01 Sun Feb 23 02:00:00 2025 UT = Sun Feb 23 02:00:00 2025 +00 Sun Apr 6 01:59:59 2025 UT = Sun Apr 6 01:59:59 2025 +00 Sun Apr 6 02:00:00 2025 UT = Sun Apr 6 03:00:00 2025 +01 Sun Feb 15 01:59:59 2026 UT = Sun Feb 15 02:59:59 2026 +01 Sun Feb 15 02:00:00 2026 UT = Sun Feb 15 02:00:00 2026 +00 Sun Mar 22 01:59:59 2026 UT = Sun Mar 22 01:59:59 2026 +00 Sun Mar 22 02:00:00 2026 UT = Sun Mar 22 03:00:00 2026 +01 Sun Feb 7 01:59:59 2027 UT = Sun Feb 7 02:59:59 2027 +01 Sun Feb 7 02:00:00 2027 UT = Sun Feb 7 02:00:00 2027 +00 Sun Mar 14 01:59:59 2027 UT = Sun Mar 14 01:59:59 2027 +00 Sun Mar 14 02:00:00 2027 UT = Sun Mar 14 03:00:00 2027 +01 Sun Jan 23 01:59:59 2028 UT = Sun Jan 23 02:59:59 2028 +01 Sun Jan 23 02:00:00 2028 UT = Sun Jan 23 02:00:00 2028 +00 Sun Mar 5 01:59:59 2028 UT = Sun Mar 5 01:59:59 2028 +00 Sun Mar 5 02:00:00 2028 UT = Sun Mar 5 03:00:00 2028 +01 Sun Jan 14 01:59:59 2029 UT = Sun Jan 14 02:59:59 2029 +01 Sun Jan 14 02:00:00 2029 UT = Sun Jan 14 02:00:00 2029 +00 Sun Feb 18 01:59:59 2029 UT = Sun Feb 18 01:59:59 2029 +00 Sun Feb 18 02:00:00 2029 UT = Sun Feb 18 03:00:00 2029 +01 Sun Dec 30 01:59:59 2029 UT = Sun Dec 30 02:59:59 2029 +01 Sun Dec 30 02:00:00 2029 UT = Sun Dec 30 02:00:00 2029 +00 Sun Feb 10 01:59:59 2030 UT = Sun Feb 10 01:59:59 2030 +00 Sun Feb 10 02:00:00 2030 UT = Sun Feb 10 03:00:00 2030 +01 Sun Dec 22 01:59:59 2030 UT = Sun Dec 22 02:59:59 2030 +01 Sun Dec 22 02:00:00 2030 UT = Sun Dec 22 02:00:00 2030 +00

3 9

DST Change in Egypt
by Ahmed Hanafy March 15, 2023

March 15, 2023

Dear Team, Seeking your support to publish an updated package which contains the new update for EGYPT DST as it will return back as mentioned on below links. Adjusting the clock - Egypt - Al-Ahram Weekly - Ahram Online<https://english.ahram.org.eg/NewsContent/50/1201/491316/AlAhram-Weekly/Egyp…> Egypt Reintroduces DST to Save Energy (timeanddate.com)<https://www.timeanddate.com/news/time/dst-egypt-2023.html> DST News - Egypt to return of Summer Time daylight saving time in 2023 (worldtimezone.com)<https://www.worldtimezone.com/dst_news/dst_news_egypt11.html> [cid:image001.png@01D9577D.AF17A070] Thanks BR [https://mediabank.ericsson.net/internet-media/Email_logo_Ericsson.png]<https://www.ericsson.com/> Ahmed Hanafy Customer Technical Manager S&R MMEA NEW S&R CU SSE Mobile: +201116114054 ahmed.hanafy(a)ericsson.com Ericsson Km 28 Cairo-Alex desert road, Smart Village B124 27-12577, Al Jizah Giza Egypt ericsson.com<https://www.ericsson.com/> [https://mediabank.ericsson.net/internet-media/Email_Message.gif]<https://www.ericsson.com/current_campaign> Our commitment to Technology for Good<https://www.ericsson.com/thecompany/sustainability-corporateresponsibility> and Diversity and Inclusion<https://www.ericsson.com/thecompany/diversity-inclusion> contributes to positive change. Follow us on: Facebook<https://www.facebook.com/ericsson> LinkedIn<https://www.linkedin.com/company/ericsson> Twitter<https://twitter.com/Ericsson> Legal entity:ERICSSON EGYPT LTD. registration number 16630, registered office in Cairo. This communication is confidential. Our email terms: www.ericsson.com/en/legal/privacy/email-disclaimer<https://www.ericsson.com/en/legal/privacy/email-disclaimer>

2 2

Timezone change announcement - Egypt
by Mohammed Amer (Skyvera Support) March 15, 2023

March 15, 2023

Hi Dears, this is to let you know that Egypt will return working with DST changes . the change will be done on the Last Friday of April 28th 2023 . I m sharing the wikipedia article : https://en.wikipedia.org/wiki/Daylight_saving_time_in_Egypt Reaching out to you to update tzdata package. Best Regards, Mohammed Amer Conversation ID: 205380e6-c356-11ed-bd31-cecd37de1d19 205380e6-c356-11ed-bd31-cecd37de1d19 f047743

1 0

DST Change in Egypt April from GMT+2 to GMT+3
by Amir Ayad March 15, 2023

March 15, 2023

Dear Team, Hope everything is great. Kindly need your support to provide us with an updated TZ package as our Government in Egypt recently declared to start applying DST timings starting from last week in April till last week in October which will impact many Ericsson charging nodes. Accordingly we need this package the soonest to start implementing on our nodes. Thanks in advance for your usual support. Best Regards, [https://www.ericsson.com]<https://www.ericsson.com/> Amir Ayad Senior Support Engineer MMEA MS NEW SSE MOBINIL 2LO Mobile: +201284336575 amir.ayad(a)ericsson.com<mailto:amir.ayad@ericsson.com> Ericsson Smart Village KM 28 Cairo/Alex Road, Bldg#86B 6580, Sixth of October City Egypt ericsson.com<https://www.ericsson.com/>

5 12

Mexico Time Change
by Neda Zaman March 14, 2023

March 14, 2023

Hello, I hope this email finds you and your team well. I wanted to inquire about the update to the rules for Mexico as they have announced they will not be following daylight saving's time as of this year. https://www.usnews.com/news/best-states/arizona/articles/2022-10-26/mexico-… Will this be reflected on the tz database? Thank you, Neda Zaman | Product Manager | UKG Ultimate Kronos Group T: 678 658 5435<tel:678%20658%205435> 400 Galleria Pkwy, Atlanta, GA, 30339, Suite 800 UKG.com<https://www.ukg.com/> | Our purpose is people. Follow UKG: LinkedIn<https://www.linkedin.com/company/ukg> | YouTube<https://www.youtube.com/channel/UCJZMTrZOfBMqMwuL4tfEsmQ> | Twitter<https://twitter.com/UKGInc>

2 1

Wrong timezone
by Minu Shie March 14, 2023

March 14, 2023

Hi, I've checked the sites that are currently using your database and all of them have the wrong timezone for Valle Hermoso, Tamaulipas, México. Which should be the same as Matamoros, Tamaulipas, México. (America/Matamoros) instead of (America/Monterrey). Source from the Government official diary in Article 5, paragraph I: https://dof.gob.mx/nota_detalle.php?codigo=5670045&fecha=28/10/2022#gsc.tab…

2 1

Building tz with gcc-13
by Martin Jansa March 13, 2023

March 13, 2023

Hello, I was building tz with gcc-13 and noticed that without explicit -std=c2x it fails to build 2022g version with: ``` zic.c:462:1: warning: ‘noreturn’ attribute ignored [-Wattributes] 462 | static ATTRIBUTE_NORETURN void | ^~~~~~ zic.c:462:27: error: expected identifier or ‘(’ before ‘void’ 462 | static ATTRIBUTE_NORETURN void | ^~~~ ``` The last code change on github in this are was: https://github.com/eggert/tz/commit/dbfcefe0c129e36e8c5acbcedf1400c1b486d962 It builds fine for me with gcc-12 without -std: ``` __STDC_VERSION__ = 201710 __has_c_attribute(noreturn) = 0 ``` and with -std=c2x: ``` __STDC_VERSION__ = 202000 __has_c_attribute(noreturn) = 0 __STRICT_ANSI__ ``` but with gcc-13 it builds only with explicit -std=c2x: ``` __STDC_VERSION__ = 202000 __has_c_attribute(noreturn) = 202202 __STRICT_ANSI__ ``` Maybe because __has_c_attribute(noreturn) returns 202202 even when __STDC_VERSION__ doesn't accept it yet? ``` __STDC_VERSION__ = 201710 __has_c_attribute(noreturn) = 202202 ``` >From https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2764.pdf it's not clear to me when exactly [[noreturn]] can be used. It says only this about the value `Drafting note: The value used for __has_c_attribute is a placeholder that is to be replaced by the editors with the year and month the proposal is accepted into the working draft.` Is it a bug in gcc or should it be handled somehow by private.h? Thanks

4 4

Fwd: New Version Notification for draft-murchison-rfc8536bis-07.txt
by Ken Murchison March 13, 2023

March 13, 2023

FYI. -------- Forwarded Message -------- Subject: New Version Notification for draft-murchison-rfc8536bis-07.txt Date: Mon, 13 Mar 2023 06:44:33 -0700 From: internet-drafts(a)ietf.org To: Arthur David Olson <arthurdavidolson(a)gmail.com>, Arthur Olson <arthurdavidolson(a)gmail.com>, Kenneth Murchison <murch(a)fastmailteam.com>, Paul Eggert <eggert(a)cs.ucla.edu> A new version of I-D, draft-murchison-rfc8536bis-07.txt has been successfully submitted by Kenneth Murchison and posted to the IETF repository. Name: draft-murchison-rfc8536bis Revision: 07 Title: The Time Zone Information Format (TZif) Document date: 2023-03-13 Group: Individual Submission Pages: 48 URL: https://www.ietf.org/archive/id/draft-murchison-rfc8536bis-07.txt Status: https://datatracker.ietf.org/doc/draft-murchison-rfc8536bis/ Html: https://www.ietf.org/archive/id/draft-murchison-rfc8536bis-07.html Htmlized: https://datatracker.ietf.org/doc/html/draft-murchison-rfc8536bis Diff: https://author-tools.ietf.org/iddiff?url2=draft-murchison-rfc8536bis-07 Abstract: This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined. This document replaces and obsoletes RFC 8536. The IETF Secretariat

1 0

two distinct limits on time zone abbreviation length in tzcode?
by Paul Eggert March 13, 2023

March 13, 2023

I just noticed that tzcode has two distinct limits on time zone abbreviation length. One is MY_TZNAME_MAX (which is 255 on GNU/Linux and I expect smaller on other platforms); the other is TZ_ABBR_MAX_LEN (which is always 16). The latter limit was introduced in 2005, here: https://mm.icann.org/pipermail/tz/2005-May/013037.html These two distinct limits can lead to confusing behavior. For example, on GNU/Linux if you compile and build tzcode date you can see this behavior: $ TZ=ABCDEFGHIJKLMNOPQ4 date Sun Mar 5 07:21:41 ABCDEFGHIJKLMNOP 2023 $ TZ=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4 date Sun Mar 5 11:22:05 UTC 2023 In the first example, the "Q" is silently dropped (it's one more than the 16-byte limit), whereas in the second example, the entire TZ string is ignored and UTC is silently substituted. I'm thinking of changing the code so that there's just one limit, presumably the higher one, so that we don't get the confusing behavior noted above. Comments welcome.

1 1

DST changes to Egypt's time starting from 28/April/2023
by Moustafa Hammouda March 12, 2023

March 12, 2023

Greetings, I would like to inform you about some planned changes to the DST in Egypt [1]. These changes were officially announced by the Egyptian government. I'm posting this excerpt and it's translation from the official government based newspaper (Ahram): ووافق مجلس الوزراء خلال اجتماعه اليوم، برئاسة الدكتور مصطفى مدبولي، على عدة > قرارات، هي: > - وافق مجلس الوزراء على مشروع قانون في شأن عودة العمل بنظام التوقيت الصيفي > . > وجاء نص مشروع القانون كالتالي: "اعتباراً من الجمعة الأخيرة من شهر أبريل، > حتى نهاية يوم الخميس الأخير من شهر أكتوبر من كل عام ميلادي، تكون الساعة > القانونية في جمهورية مصر العربية، هي الساعة بحسب التوقيت المُتبع، مُقدمة > بمقدار ستين دقيقة". *Translation:* During its meeting today, headed by Dr. Mostafa Madbouly, the Council of Ministers approved several decisions, which are: - The Council of Ministers approved a draft law regarding the return of the summer time system. The text of the draft law came as follows: “From the last Friday of April until the end of the last Thursday of October of each Gregorian year, the legal hour in the Arab Republic of Egypt is the hour according to the time followed, advanced by sixty minutes.” [1] https://gate.ahram.org.eg/News/4162139.aspx [2] https://time.is/time_zone_news/egypt_brings_back_dst [3] https://www.timeanddate.com/news/time/dst-egypt-2023.html [4] https://www.economist.com/middle-east-and-africa/2023/03/09/fiddling-with-e… [5] https://www.reuters.com/world/africa/egypt-use-daylight-saving-time-again-b… -- Best Regards, Moustafa Harbi Senior Technical Account Manager, Red Hat FZ LLC Red Hat Middle East, Turkey & Africa <https://www.redhat.com/> Office Park Building, Block A, Floor 4 PO Box 502579, Dubai, UAE mharbi(a)redhat.com M: +971585935441 <https://red.ht/sig>

1 0

Leap hour smearing...
by Arthur David Olson March 12, 2023

March 12, 2023

...on an outdoor clock in my home town of Takoma Park, Maryland. The clock has a weird intermittent-sweep minute hand. It took about eight minutes to get from 2:00 to 3:08. @dashdashado https://youtu.be/XeVLyyBSOT8

1 0

Recommendations to governments about time zone update notice period and format
by Neil Fuller March 10, 2023

March 10, 2023

The latest short-notice time zone change from Egypt, so soon after the Mexico changes, made me wonder... Would it be useful to have a canonical thread or set of links in the TZDB docs to point to for user-facing "Why hasn't my device updated?" or government-facing "Why didn't our legislation change reach citizen's devices in time?" -type questions? For example, here are recommendations/policy I know of for a couple of widely-used operating systems / platforms: Android: https://source.android.com/docs/core/connect/time/time-zone-policy-recommen… (this is relatively new) Windows: https://learn.microsoft.com/en-us/troubleshoot/windows-client/system-manage… Maybe these could be collated and extended for other consumers of TZDB. ------- I vaguely remembered there being something in the TZDB docs that says something along these lines [*] but I couldn't find it and might be getting confused with threads on the mailing list. I don't honestly expect having it written down to make a lot of difference, but the regular lack of notice and confusion about what *exactly* governments have changed makes me think there *could* be a set of recommendations. Then, governments that *want* to do the right thing could then know what to provide / expect and plan accordingly, and ones that don't try can be easily informed why things didn't work out like they may have expected. Thanks, Neil. [*] e.g. maybe something like "Many downstream users of the TZDB wait for an official TZDB release before they will produce an update to time zone behavior in consumer devices and software products. After TZDB has been updated, various parties have to perform their own integration, testing, and rollout of an update before users will see changes. These updates can be expensive, e.g. for the QA process itself and the network costs for updates to each TZDB copy. Updates may be batched with other updates and take substantial time to reach users after the TZDB release. Updates will require that affected products have a suitable update mechanism in place and are still supported." -- Google UK Limited Registered Office: 6 Pancras Square, London, N1C 4AG Registered in England Number: 3977902

4 5

Re: [tz] mandoc(1) warning in tzfile(5) regarding //
by Paul Eggert March 10, 2023

March 10, 2023

On 3/8/23 14:15, Alejandro Colomar wrote: > That patch looks good to me. If you use these: > > Reviewed-by: Alejandro Colomar <alx(a)kernel.org> Oh, we don't use those in tzdb; instead your name is mentioned in the commit message. I installed it that way. > I suggest using the project name without a > version. How about the following? > > .TH tzfile 5 "" tzdb > > (or alternatively:) > > .TH tzfile 5 "" "Time Zone Database" Yes, that should work. I installed the attached proposed patch into the tzdb development repository. Feel free to migrate this into man-pages at your convenience. No rush of course. >> I've been reluctant to do that upstream since I expect each >> downstream user has its own format for comments regarding licensing, >> SBOM, SSDF, SCA, and so forth (and if you don't know what those acronyms >> mean then I envy you :-). > > I don't :-) https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecur…

2 1

Fwd: New Version Notification for draft-murchison-rfc8536bis-06.txt
by Ken Murchison March 10, 2023

March 10, 2023

All, Here is the latest update to the TZif specification. Please give this a review and let us know if there are any errors or omissions. I'd like to start the process of getting this published as a new RFC, which will obsolete RFC 8536. -------- Forwarded Message -------- Subject: New Version Notification for draft-murchison-rfc8536bis-06.txt Date: Tue, 07 Mar 2023 07:00:48 -0800 From: internet-drafts(a)ietf.org To: Arthur David Olson <arthurdavidolson(a)gmail.com>, Arthur Olson <arthurdavidolson(a)gmail.com>, Kenneth Murchison <murch(a)fastmailteam.com>, Paul Eggert <eggert(a)cs.ucla.edu> A new version of I-D, draft-murchison-rfc8536bis-06.txt has been successfully submitted by Kenneth Murchison and posted to the IETF repository. Name: draft-murchison-rfc8536bis Revision: 06 Title: The Time Zone Information Format (TZif) Document date: 2023-03-07 Group: Individual Submission Pages: 46 URL: https://www.ietf.org/archive/id/draft-murchison-rfc8536bis-06.txt Status: https://datatracker.ietf.org/doc/draft-murchison-rfc8536bis/ Html: https://www.ietf.org/archive/id/draft-murchison-rfc8536bis-06.html Htmlized: https://datatracker.ietf.org/doc/html/draft-murchison-rfc8536bis Diff: https://author-tools.ietf.org/iddiff?url2=draft-murchison-rfc8536bis-06 Abstract: This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined. This document replaces and obsoletes RFC 8536. The IETF Secretariat

10 22

Questions About tz database
by Jaime Suazo Vacca March 9, 2023

March 9, 2023

Hello !!! Is this the right place to ask if the latest Chilean tz is going to be added to the database? Currently is not there and we have a tz change on April 2023 Thanks for any information you can share with us Best regards/Saludos Cordiales, Jaime Suazo Mining Techn. Impl. Spec. Caterpillar Caterpillar: Confidential Green

2 4

[PROPOSED] Improve tzselect explanation
by Paul Eggert March 6, 2023

March 6, 2023

* tzselect.ksh: Improve quality of "Based on the following information:" note when the user selected a time first. --- tzselect.ksh | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/tzselect.ksh b/tzselect.ksh index 41180ae9..b8f64077 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -551,6 +551,7 @@ while echo >&2 'Please select a country' \ 'whose clocks agree with yours.' doselect $countries + country_result=$select_result country=$select_result;; *) country=$countries @@ -653,12 +654,13 @@ Universal Time is now: $UTdate." echo >&2 "" echo >&2 "Based on the following information:" echo >&2 "" - case $time%$country%$region%$coord in + case $time%$country_result%$region%$coord in ?*%?*%?*%) - say >&2 " $time$newline $country$newline $region";; - ?*%?*%%) say >&2 " $time$newline $country";; - %?*%?*%) say >&2 " $country$newline $region";; - %?*%%) say >&2 " $country";; + say >&2 " $time$newline $country_result$newline $region";; + ?*%?*%%|?*%%?*%) say >&2 " $time$newline $country_result$region";; + ?*%%%) say >&2 " $time";; + %?*%?*%) say >&2 " $country_result$newline $region";; + %?*%%) say >&2 " $country_result";; %%?*%?*) say >&2 " coord $coord$newline $region";; %%%?*) say >&2 " coord $coord";; *) say >&2 " TZ='$TZ'" -- 2.37.2

1 0

Tzdb and the Sunshine Protection Act
by Brooks Harris March 5, 2023

March 5, 2023

You've seen the Sunshine Protection Act is back: Congress to consider making daylight saving time permanent https://www.axios.com/2023/03/02/daylight-saving-time-change-permanent-cong… As I read the law it would shift STDOFF by an hour, for example, America/New_York would move to -04:00 STDOFF, essentially moving "Eastern Time" into the Atlantic time zone. Historically tzdb has honored the laws as faithfully as possible so that might be the right approach. But it seems to me this would be technically disruptive, necessitating a great deal of careful modification of existing implementations. The other method is to shift DST rules to "permanent" DST. The law might arguably be interpreted this way. That might be less disruptive and leave the option of returning to DST when its no longer "permanent", as happened in the 1970s. There are many arguments for going to "permanent standard time" instead. One reason not mentioned is that it would be technically much easier and less disruptive. How will tzdb manage this?

11 22

[PROPOSED 1/2] Be more realistic in tzfile example
by Paul Eggert March 3, 2023

March 3, 2023

* tzfile.5 (TZ): Give a real-world TZ example instead of an imaginary one. --- tzfile.5 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tzfile.5 b/tzfile.5 index c3e86c62..1bd561ab 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -220,7 +220,7 @@ if there is no POSIX-style representation for such instants. If nonempty, the POSIX-style TZ string must agree with the local time type after the last transition time if present in the eight-byte data; for example, given the string -.q "WET0WEST,M3.5.0,M10.5.0/3" +.q "WET0WEST,M3.5.0/1,M10.5.0" then if a last transition time is in July, the transition's local time type must specify a daylight-saving time abbreviated .q "WEST" -- 2.37.2

1 1

Sunshine Protection Act in the news
by Arthur David Olson March 3, 2023

March 3, 2023

"Bill to make daylight saving time permanent reintroduced in Congress" https://thehill.com/homenews/nexstar_media_wire/3880009-bill-to-make-daylig… @dashdashado

1 0

Paraguay on its way to stay on DST
by Carlos Raúl Perasso March 2, 2023

March 2, 2023

On September 28, the Paraguayan Chamber of Deputies approved a bill that eliminates winter time in Paraguay. This would make Paraguay stay in DST throughout the year. The project was sent to the Senate for approval. After this, it could still have the presidential veto. If successful, the law would take effect after this weekend's time change, so the new rule should read as follows: Rule Para 2010 2022 - Oct Sun>=1 0:00 1:00 - Rule Para 2013 2022 - Mar Sun>=22 0:00 0 - I will keep you informed of the progress of the bill. Saludos, Carlos

2 2

Egypt daylight savings will be back
by Ahmad ElDardiry March 2, 2023

March 2, 2023

Hello, Egypt officially announced today that daylight savings will be applied from last Friday of April to last Thursday of October. https://www.mena.org.eg/ar/news/dbcall/table/textnews/id/10044253#:~:text=2… .

3 6

Time for a Lunar time zone?
by Tim McBrayer March 2, 2023

March 2, 2023

On the lighter side; we may need to consider going interplanetary. https://theweek.com/space/1021396/why-space-experts-want-to-establish-a-lun… https://epaper.bostonglobe.com/infinity/article_popover_share.aspx?guid=8fc… -- Tim McBrayer NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution.

4 3

MJD 60000 Tonight Feb 25 Sat Midnight UTC
by Brian Inglis Feb. 25, 2023

Feb. 25, 2023

Hi folks, Tonight at midnight UTC it was 60k days since the MJD epoch 1858-11-17: 2023 Feb 25 Sat 00:00:00+0000 MJD 60000.000000 JD 2460000.500000 NTP 3886272000 Unix 1677283200 Windows 133217568000000000 No sign of anyone at SAO acknowledging the 65th year of its use since its definition to track Sputnik's orbit on an IBM 704 from 1957-10-04 to about 1958-01-04. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

1 0

Charset for Digest Emails
by Owen Leibman Feb. 24, 2023

Feb. 24, 2023

I have been subscribed to the “tz digest”, which comes out about once a day. Whenever a non-ASCII character is part of the message, it is rendered as multiple question marks. This seems to be because the message is sent with a header: Content-Type: text/plain; charset="us-ascii" This is only a minor nuisance. However, as an experiment, I changed my subscription to receive the messages directly rather than in digest form. A message today used an emoji outside the ASCII range, and it was rendered exactly as intended. It came with the following header: Content-Type: text/plain; charset="UTF-8"; format=flowed Is there a setting that could/should be changed so that the digest is sent with the same header? This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.

5 7

Austin Group POSIX TZ changes and Time Zone Taxonomy
by Brian Inglis Feb. 23, 2023

Feb. 23, 2023

Hi folks, Saw that the Austin Group is proposing to support *some* time zones in POSIX issue 8; see: https://www.austingroupbugs.net/view.php?id=1619 TZ=Area/Location Some of the zones could be categorized as they have proposed, but that uses terminology that I don't think we would approve of, leaves a lot of zones in the tzdb unsupported and unaddressed, and omits a whole reality which I have attempted to categorize in the attached. Perhaps some here would like to come up with better facts, names, terminology, and wording, and propose an update to the Austin Group, that better reflects what exists, and what they are meant to be standardizing? If they are going to standardize this, they should either do it properly, or drop it entirely, maintaining the status quo, as they are not going to be helping with their inaccurate terminology, and limited support! -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

4 5

Re: [tz] IANA compilation problem
by Paul Eggert Feb. 22, 2023

Feb. 22, 2023

On 1/26/23 20:08, Steven Shuriff wrote: > I am getting compilation errors with the tz code involving UINTMAX_MAX. > This is happening on Windows and on VMS. Both are using older compilers. > > Windows is getting: > zic.c(1317) : error C2065: 'UINTMAX_MAX' : undeclared identifier > zic.c(2358) : warning C4116: unnamed type definition in parentheses > > > VMS is getting: > uint_fast64_t unfair_min = - ((UINTMAX_MAX % base__6 + 1) % base__6); > .................................^ > %CC-E-UNDECLARED, In the initializer for unfair_min, "UINTMAX_MAX" is not declared. > at line number 1272 in file DEVVS1$DKA0:[COMMON_INGSRC.TREASURE.IANA.iana.tmp]zic.c;33 > Failed to build zic > > > Besides upgrading the compilers (not possible at this time) is there any possible solution? Sorry, I didn't see this private email until now. Please try the attached patch, which I installed into the development repository. It fixes a portability bug present since TZDB release 2022f. As mentioned in <https://mm.icann.org/pipermail/tz/2022-December/032399.html> I'm planning to phase out support for C89, as these old compilers are not much used nowadays and the cost of maintaining the ports to these compilers is starting to outweigh the benefit. In the next release if you still need support for old compilers the plan is that you'll need to compile with -DPORT_TO_C89 and/or -DSUPPORT_C99. This is intended to be a heads-up for builders on obsolete platforms.

2 2

Palestine time zone web page
by heba.hamad Feb. 1, 2023

Feb. 1, 2023

2 1

tzdata timezone problem
by 刘宇 Jan. 31, 2023

Jan. 31, 2023

Hello: Maybe it's wrong to calculate local time by using the latest version tzdada2022g when zoneid is "America/Ojinaga". Thanks

2 1

Looking for details on timezones “right/…”
by Jens Tröger Jan. 30, 2023

Jan. 30, 2023

Hello, Today I stumbled upon timezone strings like “right/UTC”, “right/America/Jujuy”, and so forth, but I’m unable to find details on the meaning & classification of the “right/” here and how it relates to actual UTC and other timezones. I’d appreciate pointers or clarifications. Thank you kindly, Jens -- Jens Tröger https://savage.light-speed.de/

6 8

In the news: Russia wants to put illegally occupied regions to Moscow Time
by Derick Rethans Jan. 27, 2023

Jan. 27, 2023

Hi, saw this in the news: https://www.newsweek.com/russia-moscow-time-zone-ukraine-annexed-territorie… cheers, Derick

6 8

Dead PTB link
by Benjamin Drung Jan. 27, 2023

Jan. 27, 2023

Hi, I noticed that the PTB link http://www.ptb.de/de/org/4/44/441/salt.htm is dead. See attached patch (for git am) to update it to the current location. -- Benjamin Drung Debian & Ubuntu Developer

2 1

[PROPOSED 1/2] Update IDL commentary
by Paul Eggert Jan. 25, 2023

Jan. 25, 2023

--- australasia | 36 +++++++++++++++--------------------- 1 file changed, 15 insertions(+), 21 deletions(-) diff --git a/australasia b/australasia index 749b72c8..84d94b99 100644 --- a/australasia +++ b/australasia @@ -2199,24 +2199,18 @@ Zone Pacific/Efate 11:13:16 - LMT 1912 Jan 13 # Vila # an international standard, there are some places on the high seas where the # correct date is ambiguous. -# From Wikipedia <https://en.wikipedia.org/wiki/Time_zone> (2005-08-31): -# Before 1920, all ships kept local apparent time on the high seas by setting -# their clocks at night or at the morning sight so that, given the ship's -# speed and direction, it would be 12 o'clock when the Sun crossed the ship's -# meridian (12 o'clock = local apparent noon). During 1917, at the -# Anglo-French Conference on Time-keeping at Sea, it was recommended that all -# ships, both military and civilian, should adopt hourly standard time zones -# on the high seas. Whenever a ship was within the territorial waters of any -# nation it would use that nation's standard time. The captain was permitted -# to change his ship's clocks at a time of his choice following his ship's -# entry into another zone time - he often chose midnight. These zones were -# adopted by all major fleets between 1920 and 1925 but not by many -# independent merchant ships until World War II. - -# From Paul Eggert, using references suggested by Oscar van Vlijmen -# (2005-03-20): -# -# The American Practical Navigator (2002) -# http://pollux.nss.nima.mil/pubs/pubs_j_apn_sections.html?rid=187 -# talks only about the 180-degree meridian with respect to ships in -# international waters; it ignores the international date line. +# From Wikipedia <https://en.wikipedia.org/wiki/Nautical_time> (2023-01-23): +# The nautical time zone system is analogous to the terrestrial time zone +# system for use on high seas. Under the system time changes are required for +# changes of longitude in one-hour steps. The one-hour step corresponds to a +# time zone width of 15° longitude. The 15° gore that is offset from GMT or +# UT1 (not UTC) by twelve hours is bisected by the nautical date line into two +# 7°30' gores that differ from GMT by ±12 hours. A nautical date line is +# implied but not explicitly drawn on time zone maps. It follows the 180th +# meridian except where it is interrupted by territorial waters adjacent to +# land, forming gaps: it is a pole-to-pole dashed line. + +# From Paul Eggert (2023-01-23): +# The American Practical Navigator <https://msi.nga.mil/Publications/APN>, +# 2019 edition, merely says that the International Date Line +# "coincides with the 180th meridian over most of its length." -- 2.37.2

3 5

[PROPOSED 1/4] Allow “§” etc. in commentary
by Paul Eggert Jan. 24, 2023

Jan. 24, 2023

* Makefile (UNUSUAL_OK_LATIN_1): Allow all non-alphabetic, non-ASCII printable characters that are Latin-1. This is primarily for “§” and we might as well allow them all since even XEmacs 21 supports them all. --- Makefile | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 721a7452..17e3bb57 100644 --- a/Makefile +++ b/Makefile @@ -459,9 +459,10 @@ SAFE_CHARSET3= 'abcdefghijklmnopqrstuvwxyz{|}~' SAFE_CHARSET= $(SAFE_CHARSET1)$(SAFE_CHARSET2)$(SAFE_CHARSET3) SAFE_CHAR= '[]'$(SAFE_CHARSET)'-]' -# These characters are Latin-1, and so are likely to be displayable -# even in editors with limited character sets. -UNUSUAL_OK_LATIN_1 = «°±»½¾× +# These non-alphabetic, non-ASCII printable characters are Latin-1, +# and so are likely displayable even in editors like XEmacs 21 +# that have limited character sets. +UNUSUAL_OK_LATIN_1 = ¡¢£¤¥¦§¨©ª«¬®¯°±²³´µ¶·¸¹º»¼½¾¿×÷ # This IPA symbol is represented in Unicode as the composition of # U+0075 and U+032F, and U+032F is not considered alphabetic by some # grep implementations that do not grok composition. -- 2.37.2

4 7

No leap second on 2023-06-30
by Tim Parenti Jan. 20, 2023

Jan. 20, 2023

Per IERS, Bulletin C 65 (2023-01-09) https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.65 …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: Mon, 9 Jan 2023 at 05:36 Subject: Bulletin C number 65 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, 09 January 2023 Bulletin C 65 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 2023. 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

Maryland House Bill 165--permanent DST
by Arthur David Olson Jan. 19, 2023

Jan. 19, 2023

This year's session of the Maryland state legislature is off and running. On Monday, Delegate Crosby's bill 165 was read for the first time; it would put Maryland on permanent Daylight Saving Time. A similar bill was introduced last year; it passed the House but died in a Senate committee. The bill is contingent on federal enabling legislation and on adoption of permanent DST by neighboring jurisdictions. Once the contingencies are met, the bill specifies that "this Act shall take effect on the earlier of the second Sunday of March or the first Sunday of November." So yes, if the contingencies are met on October 31, there'd be less than a week's notice of cancellation of setting clocks back. I plan to be in touch with one of my representatives to suggest a parsimonious improvement: change "earlier" to "later." There are links to the bill's text and to a status page below. @dashdashado https://mgaleg.maryland.gov/2023rs/bills_noln/hb/fhb0165.pdf https://mgaleg.maryland.gov/mgawebsite/Legislation/Details/hb0165?ys=2023rs

1 0

not getting proper timezone for few countries
by Bhardwaj, vanshika Jan. 18, 2023

Jan. 18, 2023

Hello , We are using tzdata vendor source latest version which is 2022g in our code ,which basically return the timezones value of the country as per the mapping but we found for few of the countries we are getting alphanumeric value as an output of time-zone, like if we select India so timezones we are getting for India is IST as an output which is expected ,but if we select brasalia so timezones for Brasalia we are getting is -03 , which is alpha-numeric value , so can u please tell us when u are going to add the timezones for the rest of the countries or it will be same. Hope u will reply soon. With Regards, Vanshika Bhardwaj Associate Engineer(Eaton)

2 1

Swiss time selectable for Germany
by Benjamin Drung Jan. 17, 2023

Jan. 17, 2023

Hi, I tried tzselect for Germany and was presented with following question: Please select one of the following timezones. 1) Swiss time 2) Germany (most areas), Scandinavia We do not use Swiss time in Germany. I did some research: Germany switched to summertime in 1980 and Swiss in 1981. There is Büsingen am Hochrhein which followed Swiss and therefore deviated from Germany only in 1980. Should zone1970.tab reflect the current status (i.e. drop DE from Europe/Zurich and rename "Germany (most areas)" to "Germany" in the comments)? -- Benjamin Drung Debian & Ubuntu Developer

10 23

[PROPOSED] Be more consistent about MSK/MSD
by Paul Eggert Jan. 17, 2023

Jan. 17, 2023

* NEWS: Mention this. * europe (Europe/Volgograd, Europe/Kirov): Use the abbreviations MSK/MSD when using Moscow time, since that’s what other Russian timezones do. This fixes an inconsistency introduced in 2016g. --- NEWS | 6 ++++++ europe | 18 +++++++++--------- 2 files changed, 15 insertions(+), 9 deletions(-) diff --git a/NEWS b/NEWS index 7bd80803..fc35046c 100644 --- a/NEWS +++ b/NEWS @@ -26,6 +26,12 @@ Unreleased, experimental changes since 1970. (Thanks to Almaz Mingaleev.) This affects some pre-1948 timestamps. The old data are now in 'backzone'. + Changes to past time zone abbreviations + + When observing Moscow time, Europe/Kirov and Europe/Volgograd now + use the abbreviations MSK/MSD instead of numeric abbreviations, + for consistency with other timezones observing Moscow time. + Changes to code You can now tell tzselect local time, to simplify later choices. diff --git a/europe b/europe index 89bc3a28..b784d0ee 100644 --- a/europe +++ b/europe @@ -2656,13 +2656,13 @@ Zone Europe/Volgograd 2:57:40 - LMT 1920 Jan 3 3:00 - +03 1930 Jun 21 4:00 - +04 1961 Nov 11 4:00 Russia +04/+05 1988 Mar 27 2:00s - 3:00 Russia +03/+04 1991 Mar 31 2:00s + 3:00 Russia MSK/MSD 1991 Mar 31 2:00s 4:00 - +04 1992 Mar 29 2:00s - 3:00 Russia +03/+04 2011 Mar 27 2:00s - 4:00 - +04 2014 Oct 26 2:00s - 3:00 - +03 2018 Oct 28 2:00s + 3:00 Russia MSK/MSD 2011 Mar 27 2:00s + 4:00 - MSK 2014 Oct 26 2:00s + 3:00 - MSK 2018 Oct 28 2:00s 4:00 - +04 2020 Dec 27 2:00s - 3:00 - +03 + 3:00 - MSK # From Paul Eggert (2016-11-11): # Europe/Saratov covers: @@ -2693,11 +2693,11 @@ Zone Europe/Saratov 3:04:18 - LMT 1919 Jul 1 0:00u Zone Europe/Kirov 3:18:48 - LMT 1919 Jul 1 0:00u 3:00 - +03 1930 Jun 21 4:00 Russia +04/+05 1989 Mar 26 2:00s - 3:00 Russia +03/+04 1991 Mar 31 2:00s + 3:00 Russia MSK/MSD 1991 Mar 31 2:00s 4:00 - +04 1992 Mar 29 2:00s - 3:00 Russia +03/+04 2011 Mar 27 2:00s - 4:00 - +04 2014 Oct 26 2:00s - 3:00 - +03 + 3:00 Russia MSK/MSD 2011 Mar 27 2:00s + 4:00 - MSK 2014 Oct 26 2:00s + 3:00 - MSK # From Tim Parenti (2014-07-03), per Oscar van Vlijmen (2001-08-25): # Europe/Samara covers... -- 2.37.2

1 0

localtime_r multiple times slower for Europe/Moscow timezone
by Benjamin Drung Jan. 11, 2023

Jan. 11, 2023

Hi, a Ubuntu user has been reporting in https://launchpad.net/bugs/868395 that the Europe/Moscow timezone is multiple times slower than other timezones. Here is the example bug.c code: ``` #include <time.h> #include <stdio.h> int main() { time_t t = time(0); int i; struct tm result; for(i=0; i < 10000000; i++) localtime_r(&t, &result); puts(ctime(&t)); return 0; } ``` Compile and run this code: ``` gcc -o bug bug.c time TZ=Etc/UTC ./bug time TZ=Europe/Berlin ./bug time TZ=Europe/Moscow ./bug ``` The result on my machine is that Etc/UTC, Europe/Berlin, and other timezones take around 250 to 400 ms, but Europe/Moscow takes 1200 ms. The result is the same when running in a Debian unstable, Ubuntu 22.04 (jammy) and Ubuntu 23.04 (lunar) chroot. Is that a bug? If yes, is that a bug in glibc? -- Benjamin Drung Debian & Ubuntu Developer

5 6

[PROPOSED 1/2] Fix stray ‘\’ in tzselect
by Paul Eggert Jan. 11, 2023

Jan. 11, 2023

* tzselect.ksh: Remove stray backslash that messed up the wording of a diagnostic. This glitch was introduced in commit 13980693084c36e0275828d8d46d9d9e8975be0d dated Wed Jun 27 11:24:09 2018 -0700. --- tzselect.ksh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tzselect.ksh b/tzselect.ksh index 87baaa5..cbfc677 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -401,7 +401,7 @@ while BEGIN { FS = "\t" } { print $NF } '` - echo >&2 'Please select one of the following timezones,' \ + echo >&2 'Please select one of the following timezones,' echo >&2 'listed roughly in increasing order' \ "of distance from $coord". doselect $regions -- 2.39.0

1 1

[PROPOSED] Omit check_sorted dependencies no longer needed
by Paul Eggert Jan. 10, 2023

Jan. 10, 2023

* Makefile (check_sorted): Omit unnecessary dependencies on iso3166.tab, zone.tab, zone1970.tab. They should have been removed in commit 1bb4263bb1716fe3ba63b26600adc9c32f1fe16e dated 2019-06-22 13:55:46 -0700. --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 8bee50d..721a745 100644 --- a/Makefile +++ b/Makefile @@ -837,7 +837,7 @@ check_slashed_abbrs: $(TDATA_TO_CHECK) CHECK_CC_LIST = { n = split($$1,a,/,/); for (i=2; i<=n; i++) print a[1], a[i]; } -check_sorted: backward backzone iso3166.tab zone.tab zone1970.tab +check_sorted: backward backzone $(AWK) '/^Link/ {printf "%.5d %s\n", g, $$3} !/./ {g++}' \ backward | LC_ALL=C sort -cu $(AWK) '/^Zone/ {print $$2}' backzone | LC_ALL=C sort -cu -- 2.39.0

1 0

(no subject)
by Alfred Finamore Jan. 10, 2023

Jan. 10, 2023

Request

1 0

Re: [tz] tz Digest, Vol 136, Issue 11
by nadir altinbas Jan. 8, 2023

Jan. 8, 2023

There are 195 countries in the world today.As mentioned in ( https://www.worldometers.info/geography/how-many-countries-are-there-in-the…) About Today's Topics:. T?rkiye (Jonathan Leffler); My own comment is to be written as" Republic of Turkiye (Turkiye) " Thank Nadir Altinbas e:nadiraltinbas@yahoo.com n.altinbas On Sunday, January 8, 2023 at 03:00:07 PM GMT+3, tz-request(a)iana.org <tz-request(a)iana.org> wrote: Send tz mailing list submissions to tz(a)iana.org To subscribe or unsubscribe via the World Wide Web, visit https://mm.icann.org/mailman/listinfo/tz or, via email, send a message with subject or body 'help' to tz-request(a)iana.org You can reach the person managing the list at tz-owner(a)iana.org When replying, please edit your Subject line so it is more specific than "Re: Contents of tz digest..." Today's Topics: 1. T?rkiye (Jonathan Leffler) ---------------------------------------------------------------------- Message: 1 Date: Sat, 7 Jan 2023 21:47:15 -0700 From: Jonathan Leffler <jonathan.leffler(a)gmail.com> To: Time Zone Mailing List <tz(a)iana.org> Subject: [tz] T?rkiye Message-ID: <CAH+RLGEKNgZK4c9e4rdO6nmU-tMHnZ3+cXMV9=6LVaJ7VvDAJg(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" >From the Los Angeles Times, 2023-01-05 (summary from an email dated 2023-01-06): Ceding to a longstanding Turkish demand, the State Department on Thursday > agreed to begin spelling the country?s name in Turkish > <https://click.email.latimes.com/?qs=fff6b852d8f4b17927eabd337816fdb1705edee…> in > its official documents. Turkey will now be referred to as ?T?rkiye,? > Wilkinson reported. https://www.latimes.com/politics/story/2023-01-05/state-department-will-now… -- Jonathan Leffler <jonathan.leffler(a)gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."

1 0

Türkiye
by Jonathan Leffler Jan. 8, 2023

Jan. 8, 2023

>From the Los Angeles Times, 2023-01-05 (summary from an email dated 2023-01-06): Ceding to a longstanding Turkish demand, the State Department on Thursday > agreed to begin spelling the country’s name in Turkish > <https://click.email.latimes.com/?qs=fff6b852d8f4b17927eabd337816fdb1705edee…> in > its official documents. Turkey will now be referred to as “Türkiye,” > Wilkinson reported. https://www.latimes.com/politics/story/2023-01-05/state-department-will-now… -- Jonathan Leffler <jonathan.leffler(a)gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."

1 0

Re: [tz] ptrdiff_t changes in tzcode
by Paul Eggert Jan. 7, 2023

Jan. 7, 2023

On 2022-12-12 08:12, Christos Zoulas wrote: > How about changing it then to be: > > sum <= (ptrdiff_t)min(PTRDIFF_MAX, SIZE_MAX) > > This does the check explicitly and avoids the signed/unsigned warning? It is also what the #else part of the code does... This pattern > lives in many places, so we could put the RHS of the expression to a #define? Sure, we can do that. The attached proposed patch (installed in the development repository) uses a new macro INDEX_MAX to capture this notion. This shouldn't change behavior (or even generated code) but can help clarify things. (Although I'm not a fan of casts I don't see how to avoid it here.) >>> There are also a bunch of places now where you get sign comparison warnings (where ptrdiff_t is compared to size_t, like sizeof() or >>> the result of strlen(3). That's OK, they're false alarms: GCC and Clang go overboard in this department. To pacify the compilers you can compile with -Wno-sign-compare as suggested in Makefile's GCC_DEBUG_FLAGS macro. > I think that the ptrdiff_t changes make things more complicated... Yes, it's a tradeoff between complexity now, and simplicity/safety in the long run. Once we can assume C23 (say, 30 years from now!) we can get rid of the trickier code that ports to C17 and earlier. In the meantime as C23 becomes more popular we can start using the simpler code. (I did resist the temptation in the tricky code to write "itemsize**nitems_alloc", which though correct doesn't mean what it looks like....) >> By the way, I'd been meaning to try to sync tzdb localtime.c with NetBSD's at some point. Shouldn't be that hard, I'd think, and might help get bugs fixed faster (in both directions). > > That would be great! OK, thanks, I'll add that to my list of things to do.

6 14

Split America into North America and South America
by Benjamin Drung Jan. 7, 2023

Jan. 7, 2023

Hi, debconf [1] for the tzdata Debian/Ubuntu package ask for the geographic area (e.g. Europe, Asia, etc) and then for the city inside this area. The resulting timezone is $area/$city. While working on the debconf template, I noticed that the America directory is the biggest with 157 cities. Having to find the correct city in that big list can take some time. The second biggest area is Asia with 90 countries. The timezones are split by continent/ocean. The Afro-Eurasia continent is split into Africa, Asia, Europe, but America is not split into North America and South America. For consistency I suggest to split America into North America and South America to have all seven continents present [2]. The git repository already separate northamerica and southamerica files. [1] https://en.wikipedia.org/wiki/Debian_configuration_system [2] https://en.wikipedia.org/wiki/Continent -- Benjamin Drung Debian & Ubuntu Developer

7 8

Re: [tz] Split America into North America and South America
by dpatte Jan. 6, 2023

Jan. 6, 2023

Personally, I'd like to at least see 'America' renamed 'Americas', to both differentiate from the nickname for the USA, and to show there two continents (by traditional naming). ----- Original Message ----- From: Clive D.W. Feather via tz [mailto:tz@iana.org] To: "Wolfgang Keller" <wolfgangkeller(a)gmail.com> Cc: tz(a)iana.org Sent: Fri, 6 Jan 2023 21:46:47 +0000 Subject: Re: [tz] Split America into North America and South America Wolfgang Keller via tz said: > Hi, > let us consider what conventions for the number and separations of > continents exist. According to > > https://en.wikipedia.org/w/index.php?title=Continent&oldid=1131827063#N… > there exist (at least) five common conventions for the number and > separation of continents: > > a) 4 continents (Afro-Eurasia (Old World), America (New World), > Australia, Antarctica > b) 5 continents (Africa, Eurasia, America, Antarctica, Australia) > c) 6 continents, combined-Eurasia (Africa, Eurasia, North America, > South America, Antarctica, Australia) > d) 6 continents, combined-America (Africa, Asia, Europe, America, > Antarctica, Australia) > e) 7 continents (Africa, Asia, Europe, North America, South America, > Antarctica, Australia) You've forgotten Zealandia, which some consider to be a continent. > For the prevalence of these separations (prevalence of c)-e) taken > from the linked section of the Wikipedia article) > a) is to my knowledge motivated by geology > c) is is mostly used in Russia and some parts of Eastern Europe. > d) is taught in some countries where Romance languages are spoken and in Greece > e) is the model taught in most English-speaking countries > > So the central question that the problem reduces to is: which > separation of continents should tzdata implicitly endorse by its data > structures? If I were to ask, I would immediately say a) because this > is the only convention of this list that is motivated by science > (geology) and not by politics or history, I disagree. e is justifiable by geography: a continent doesn't have to be the largest contiguous landmass; it can be bordered by an isthmus or mountain range just as much as a puddle. But I don't see the need for this split. The division was made for the few humans who work with the raw data, not for the general public and certainly not for geologists. It works, so don't break it. -- Clive D.W. Feather | If you lie to the compiler, Email: clive(a)davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

2 1

Request for Russian Antarctic stations
by Benjamin Drung Jan. 6, 2023

Jan. 6, 2023

Hi, Ubuntu bug https://launchpad.net/bugs/1457285 requests to add Russian Antarctic research stations to tzdata. They are: AQ -6212-05858 Antarctica/Bellingshausen Bellingshausen Station, Vaterloo Island, GMT-4 AQ -7046+01149 Antarctica/Novolasarevskaya Novolasarevskaya Station, GMT AQ -6739+04530 Antarctica/Molodezhnaya Molodezhnaya Station, GMT+3 AQ -6633+09300 Antarctica/Mirniy Mirniy Station, GMT+7 AQ -6930+15923 Antarctica/Leningradskaya Leningradskaya Station, GMT+10 AQ -7445-13648 Antarctica/Russkaya Russkaya Station, GMT-6 AQ -6922+07623 Antarctica/Progress Progress Station, GMT+5 AQ -6944+07342 Antarctica/Druzhnaya Druzhnaya Station, GMT+5 Please mean that GMT data given are POSIX inversed. -- Benjamin Drung Debian & Ubuntu Developer

5 4

[PROPOSED] A couple more ptrdiff_t overflow safety checks
by Paul Eggert Jan. 4, 2023

Jan. 4, 2023

* private.h (TYPE_BIT): Now returns a signed value. * zdump.c (sumsize, xmalloc): Now takes signed args, like the result. (xstrsize): New function. (tzalloc, saveabbr): Use xstrsize to properly catch strings so long that their sizes do not fit into ptrdiff_t. Although quite implausible in real-life uses, it is possible according to the C standard. --- private.h | 2 +- zdump.c | 28 ++++++++++++++++++++-------- 2 files changed, 21 insertions(+), 9 deletions(-) diff --git a/private.h b/private.h index 03ee4d10..b638e9e4 100644 --- a/private.h +++ b/private.h @@ -805,7 +805,7 @@ ATTRIBUTE_REPRODUCIBLE time_t time2posix_z(timezone_t, time_t); ** Finally, some convenience items. */ -#define TYPE_BIT(type) (sizeof(type) * CHAR_BIT) +#define TYPE_BIT(type) (CHAR_BIT * (ptrdiff_t) sizeof(type)) #define TYPE_SIGNED(type) (((type) -1) < 0) #define TWOS_COMPLEMENT(t) ((t) ~ (t) 0 < 0) diff --git a/zdump.c b/zdump.c index 98537f4e..b93910ed 100644 --- a/zdump.c +++ b/zdump.c @@ -133,9 +133,9 @@ size_overflow(void) } /* Return A + B, exiting if the result would overflow either ptrdiff_t - or size_t. */ + or size_t. A and B are both nonnegative. */ ATTRIBUTE_REPRODUCIBLE static ptrdiff_t -sumsize(size_t a, size_t b) +sumsize(ptrdiff_t a, ptrdiff_t b) { #ifdef ckd_add ptrdiff_t sum; @@ -148,10 +148,22 @@ sumsize(size_t a, size_t b) size_overflow(); } +/* Return the size of of the string STR, including its trailing NUL. + Report an error and exit if this would exceed INDEX_MAX which means + pointer subtraction wouldn't work. */ +static ptrdiff_t +xstrsize(char const *str) +{ + size_t len = strlen(str); + if (len < INDEX_MAX) + return len + 1; + size_overflow(); +} + /* Return a pointer to a newly allocated buffer of size SIZE, exiting - on failure. SIZE should be nonzero. */ + on failure. SIZE should be positive. */ ATTRIBUTE_MALLOC static void * -xmalloc(size_t size) +xmalloc(ptrdiff_t size) { void *p = malloc(size); if (!p) { @@ -253,7 +265,7 @@ tzalloc(char const *val) static ptrdiff_t fakeenv0size; void *freeable = NULL; char **env = fakeenv, **initial_environ; - size_t valsize = strlen(val) + 1; + ptrdiff_t valsize = xstrsize(val); if (fakeenv0size < valsize) { char **e = environ, **to; ptrdiff_t initial_nenvptrs = 1; /* Counting the trailing NULL pointer. */ @@ -410,13 +422,13 @@ saveabbr(char **buf, ptrdiff_t *bufalloc, struct tm const *tmp) if (HAVE_LOCALTIME_RZ) return ab; else { - size_t ablen = strlen(ab); - if (*bufalloc <= ablen) { + ptrdiff_t absize = xstrsize(ab); + if (*bufalloc < absize) { free(*buf); /* Make the new buffer at least twice as long as the old, to avoid O(N**2) behavior on repeated calls. */ - *bufalloc = sumsize(*bufalloc, ablen + 1); + *bufalloc = sumsize(*bufalloc, absize); *buf = xmalloc(*bufalloc); } -- 2.37.2

1 0

Questions on tzname and tm_zone
by Patrik Lantto Dec. 31, 2022

Dec. 31, 2022

Dear all, I have a few questions regarding how the tzdb code handles tzname and tm_zone: * The define HAVE_TZNAME have three different "settings"; 0 if tzname is not supported, 1 to support tzname defined by the system library and 2 to support and define tzname. In the code though, when defining tzname it also adds the value of TZ_TIME_T which reduces the options. Basically, if time_tz is defined to another datatype that time_t, tzname cannot be defined by the system library since setting HAVE_TZNAME to 1 would still define tzname (around line 195 of localtime.c). Is there a reason for this behaviour (which is also similar for USG_COMPAT)? In my platform we define a new 64 bit datatype, but would still need tzname as defined by the system library. * In case of an invalid timezone, the behaviour of tzname and tm_zone behaves differently; tzname would be set to WILDABBR (which is possible to define), but if localtime is called tm_zone will be set to "UTC" while if gmtime is called, tm_zone is set to "-00" and if offtime is called (with a non-0 offset) tm_zone is WILDABBR. It seems somewhat inconsistent, so is this by design? * The way tzname is updated (in settzname) in settzname is that it first set tzname[0] and tzname[1] to either WILDABBR or UTC, and then possibly update with the correct names. While tzname is not considered thread safe, this way writing to tzname twice means that even call to tzset with the same timezone could affect other threads reading tzname. Not a huge risk, but still possible. Is this something to consider in the implementation? * Since tzname is not thread safe, and due to the way tm_zone is handled it is somewhat hard to detect if a TZ string is valid or not. Is there a recommended way to detect an invalid string? Best regards, Patrik Lantto -- Patrik Lantto - patrik.lantto(a)wisi.se - +46 13 210918

2 1

[PROPOSED] Support leap-seconds.list tombstone
by Paul Eggert Dec. 23, 2022

Dec. 23, 2022

From: Paul Eggert <eggert@trombone> This change looks forward to the possibility of leap seconds being discontinued by 2035. If and when that happens, the expiration date on the leap-seconds.list file is likely to stop being maintained, as there will be no need to issue new versions of leap-seconds.list every six months. Although the details have not been decided, for now assume that the last edition of leap-seconds.list will simply lack an expiration-date line. * leapseconds.awk: If the input lacks an expiration line like ‘#@ 3896899200’, do not treat it as if ‘#@ 0’ were present, as that would mean an expiration date of 1900-01-01. Instead, do not output an expiration date; just output a comment saying that there is no expiration date. Similarly for update dates and input lacking lines like ’#$ 3676924800’. --- NEWS | 3 +++ leapseconds.awk | 50 ++++++++++++++++++++++++++++++------------------- 2 files changed, 34 insertions(+), 19 deletions(-) diff --git a/NEWS b/NEWS index 9ac3367..5510823 100644 --- a/NEWS +++ b/NEWS @@ -42,6 +42,9 @@ Unreleased, experimental changes 'restrict' keyword consistently with their documentation. This may allow future optimizations. + leapseconds.awk can now process a leap seconds file that never + expires; this might be useful if leap seconds are discontinued. + Changes to commentary Note that leap seconds are planned to be discontinued by 2035. diff --git a/leapseconds.awk b/leapseconds.awk index b6c48bc..7d2556b 100644 --- a/leapseconds.awk +++ b/leapseconds.awk @@ -104,18 +104,23 @@ BEGIN { } END { - sstamp_to_ymdhMs(expires, ss_NTP) - print "" - print "# UTC timestamp when this leap second list expires." - print "# Any additional leap seconds will come after this." - if (! EXPIRES_LINE) { - print "# This Expires line is commented out for now," - print "# so that pre-2020a zic implementations do not reject this file." + + if (expires) { + sstamp_to_ymdhMs(expires, ss_NTP) + + print "# UTC timestamp when this leap second list expires." + print "# Any additional leap seconds will come after this." + if (! EXPIRES_LINE) { + print "# This Expires line is commented out for now," + print "# so that pre-2020a zic implementations do not reject this file." + } + printf "%sExpires %.4d\t%s\t%.2d\t%.2d:%.2d:%.2d\n", \ + EXPIRES_LINE ? "" : "#", \ + ss_year, monthabbr[ss_month], ss_mday, ss_hour, ss_min, ss_sec + } else { + print "# (No Expires line, since the expires time is unknown.)" } - printf "%sExpires %.4d\t%s\t%.2d\t%.2d:%.2d:%.2d\n", \ - EXPIRES_LINE ? "" : "#", \ - ss_year, monthabbr[ss_month], ss_mday, ss_hour, ss_min, ss_sec # The difference between the NTP and POSIX epochs is 70 years # (including 17 leap days), each 24 hours of 60 minutes of 60 @@ -124,15 +129,22 @@ END { print "" print "# POSIX timestamps for the data in this file:" - sstamp_to_ymdhMs(updated, ss_NTP) - printf "#updated %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \ - updated - epoch_minus_NTP, \ - ss_year, ss_month, ss_mday, ss_hour, ss_min, ss_sec - sstamp_to_ymdhMs(expires, ss_NTP) - printf "#expires %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \ - expires - epoch_minus_NTP, \ - ss_year, ss_month, ss_mday, ss_hour, ss_min, ss_sec - + if (updated) { + sstamp_to_ymdhMs(updated, ss_NTP) + printf "#updated %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \ + updated - epoch_minus_NTP, \ + ss_year, ss_month, ss_mday, ss_hour, ss_min, ss_sec + } else { + print "#(updated time unknown)" + } + if (expires) { + sstamp_to_ymdhMs(expires, ss_NTP) + printf "#expires %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \ + expires - epoch_minus_NTP, \ + ss_year, ss_month, ss_mday, ss_hour, ss_min, ss_sec + } else { + print "#(expires time unknown)" + } printf "\n%s", last_lines } -- 2.38.1

1 0

Re: [tz] [PROPOSED] Mention the planned obsolescence of leap seconds
by Brian Inglis Dec. 22, 2022

Dec. 22, 2022

On 2022-12-20 17:25, Paul Eggert via tz wrote: > + Changes to commentary > + Note that leap seconds are planned to be discontinued by 2035. > + This affects time stamps during the leap second era (1972–2035). > +Leap seconds were introduced in 1972 to accommodate the > +difference between atomic time and the less-regular rotation of the earth. > +Unfortunately they caused so many problems with civil Civil (e.g. legal etc.) time keeping is not the problem, it is mainly proprietary computer systems and applications, not adequately programmed to deal with the realities of time keeping. > +timekeeping that they > +are <a href="https://www.bipm.org/en/cgpm-2022/resolution-4">planned > +to be discontinued by 2035</a>, with some as-yet-undetermined > +mechanism replacing them, perhaps after the year 2135. > +Despite their impending obsolescence, a record of leap seconds is still > +needed to resolve timestamps from 1972 through 2035. I would expect astronomers and physicists to have divergent views, but both use software which handles varieties of time bases, scales, and conversions. It seems likely that other scientists and disciplines with time concerns would line up behind one or the other, depending on whether their focus is civil, geocentric, or longer term in some way, or more artificial on accuracy, calibration, precision or other short term characteristics. > <a href="https://www.ucolick.org/~sla/leapsecs/"><abbr>UTC</abbr> > might be redefined > without Leap Seconds</a> gives pointers on this > +contentious issue. > +The General Conference on Weights and Measures > +<a href="https://www.bipm.org/en/cgpm-2022/resolution-4">voted in 2022</a> > +to discontinue the use of leap seconds by 2035, replacing them with an > +as-yet-undetermined scheme some time after the year 2135. Expect every lawyer, in any case involving time stamped records, to jump on the technicality of any significant deviation of time keeping from solar time, which is the legal basis in most English common law jurisdictions, possibly also in some continental code and Scandinavian/Nordic jurisdictions e.g. Denmark: https://www.dr.dk/nyheder/indland/uret-paa-din-telefon-viser-en-ulovlig-tid https://www-dr-dk.translate.goog/nyheder/indland/uret-paa-din-telefon-viser… -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

1 0

DST in the news
by Arthur David Olson Dec. 22, 2022

Dec. 22, 2022

A 538 piece on the merits and demerits of permanent standard time and permanent daylight time. https://projects.fivethirtyeight.com/daylight-saving-time/ --ado

1 0

[PROPOSED] Document deprecation of ctime, asctime.
by Paul Eggert Dec. 21, 2022

Dec. 21, 2022

--- newctime.3 | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/newctime.3 b/newctime.3 index e25d841..2790c81 100644 --- a/newctime.3 +++ b/newctime.3 @@ -11,13 +11,13 @@ asctime, ctime, difftime, gmtime, localtime, mktime \- convert date and time .PP .BR "extern char *tzname[];" " /\(** (optional) \(**/" .PP -.B char *ctime(time_t const *clock); +.B [[deprecated]] char *ctime(time_t const *clock); .PP .B char *ctime_r(time_t const *clock, char *buf); .PP .B double difftime(time_t time1, time_t time0); .PP -.B char *asctime(struct tm const *tm); +.B [[deprecated]] char *asctime(struct tm const *tm); .PP .B "char *asctime_r(struct tm const *restrict tm," .B " char *restrict result);" @@ -91,6 +91,15 @@ introduction of UTC and are some other flavor of Universal Time (UT). Some implementations support leap seconds, in contradiction to POSIX. .PP The +.B ctime +function is deprecated starting in C23. +Callers can use +.B localtime_r +and +.B strftime +instead. +.PP +The .B localtime and .B gmtime @@ -128,6 +137,10 @@ converts a time value contained in a structure to a string, as shown in the above example, and returns a pointer to the string. +This function is deprecated starting in C23. +Callers can use +.B strftime +instead. .PP The .B mktime -- 2.38.1

1 0

Windows build failures
by Manuela Friedrich Dec. 21, 2022

Dec. 21, 2022

Hello Paul, I noticed new Windows build failures with the latest tz code from git. Hopefully you can shed some light on these. Error 1 d:\iana\tmp\private.h(704): error C2373: 'restrict': redefinition; different type modifiers d:\iana\tmp\private.h(704): note: see declaration of 'restrict' d:\iana\tmp\private.h(780): error C2373: 'restrict': redefinition; different type modifiers d:\iana\tmp\private.h(780): note: see declaration of 'restrict' d:\iana\tmp\private.h(781): error C2371: 'restrict': redefinition; different basic types d:\iana\tmp\private.h(780): note: see declaration of 'restrict' Error 2 zic.c(154): error C2146: syntax error: missing ')' before identifier 'file' zic.c(154): error C2061: syntax error: identifier 'file' zic.c(154): error C2059: syntax error: ';' zic.c(154): error C2059: syntax error: ',' zic.c(154): error C2059: syntax error: ')' Thank you! Kind Regards Manuela Friedrich

2 5

[PROPOSED] Mention the planned obsolescence of leap seconds
by Paul Eggert Dec. 21, 2022

Dec. 21, 2022

--- NEWS | 4 ++++ theory.html | 15 ++++++++++++++- tz-link.html | 8 ++++++-- 3 files changed, 24 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index 9b2d202..9ac3367 100644 --- a/NEWS +++ b/NEWS @@ -42,6 +42,10 @@ Unreleased, experimental changes 'restrict' keyword consistently with their documentation. This may allow future optimizations. + Changes to commentary + + Note that leap seconds are planned to be discontinued by 2035. + Release 2022g - 2022-11-29 08:58:31 -0800 diff --git a/theory.html b/theory.html index fbbb9e4..88bf720 100644 --- a/theory.html +++ b/theory.html @@ -818,7 +818,8 @@ href="https://www.dissentmagazine.org/blog/booked-a-global-history-of-time-vanes <li> The relationship between POSIX time (that is, <abbr>UTC</abbr> but ignoring <a href="https://en.wikipedia.org/wiki/Leap_second">leap - seconds</a>) and <abbr>UTC</abbr> is not agreed upon after 1972. + seconds</a>) and <abbr>UTC</abbr> is not agreed upon. + This affects time stamps during the leap second era (1972–2035). Although the POSIX clock officially stops during an inserted leap second, at least one proposed standard has it jumping back a second instead; and in @@ -1268,6 +1269,18 @@ between now and the future time. <section> <h2 id="leapsec">Leap seconds</h2> +<p> +Leap seconds were introduced in 1972 to accommodate the +difference between atomic time and the less-regular rotation of the earth. +Unfortunately they caused so many problems with civil +timekeeping that they +are <a href="https://www.bipm.org/en/cgpm-2022/resolution-4">planned +to be discontinued by 2035</a>, with some as-yet-undetermined +mechanism replacing them, perhaps after the year 2135. +Despite their impending obsolescence, a record of leap seconds is still +needed to resolve timestamps from 1972 through 2035. +</p> + <p> The <code><abbr>tz</abbr></code> code and data can account for leap seconds, thanks to code contributed by Bradley White. diff --git a/tz-link.html b/tz-link.html index d3b3766..608393f 100644 --- a/tz-link.html +++ b/tz-link.html @@ -1078,8 +1078,12 @@ leap second: its history and possible future</a>. <a href="https://www.ucolick.org/~sla/leapsecs/"><abbr>UTC</abbr> might be redefined without Leap Seconds</a> gives pointers on this -contentious issue, which was active until 2015 and could become active -again.</li> +contentious issue. +The General Conference on Weights and Measures +<a href="https://www.bipm.org/en/cgpm-2022/resolution-4">voted in 2022</a> +to discontinue the use of leap seconds by 2035, replacing them with an +as-yet-undetermined scheme some time after the year 2135. +</li> </ul> </section> -- 2.38.1

1 0

[PROPOSED] Use ‘restrict’ more consistently with standards
by Paul Eggert Dec. 20, 2022

Dec. 20, 2022

Previously, I assumed that if the declaration of a function F declared an argument via ‘T *restrict ARG’ then the compiler could take advantage of the ‘restrict’ when compiling F’s definition. However, apparently this is not the case: a top-level ‘restrict’ like that has no effect semantically unless it’s present in F’s definition. Fix this by using ‘restrict’ consistently in both declarations and definitions of functions where POSIX or the NetBSD API specifies ‘restrict’. (As an exception, do not use ‘restrict’ in tzfree’s argument as this appears to be a typo in NetBSD.) Do not bother using ‘restrict’ in internal functions, as this change is for consistency not for optimization. This change was prompted by a bug report for compiling on MS-Windows; see https://mm.icann.org/pipermail/tz/2022-December/032451.html Although the change does not fix the MS-Windows situation, the idea is to fix the MS-Windows issue another way. * asctime.c (asctime_r): * localtime.c (localtime_rz, localtime_r, gmtime_r, mktime_z): * private.h (asctime) [HAVE_INCOMPATIBLE_CTIME_R]: * strftime.c (strftime_l, strftime): Use ‘restrict’ consistently when POSIX or tzcode’s doc say so. --- NEWS | 4 ++++ asctime.c | 2 +- localtime.c | 9 +++++---- private.h | 2 +- strftime.c | 6 ++++-- 5 files changed, 15 insertions(+), 8 deletions(-) diff --git a/NEWS b/NEWS index 98cc14f..9b2d202 100644 --- a/NEWS +++ b/NEWS @@ -38,6 +38,10 @@ Unreleased, experimental changes '[[noreturn]] static void usage(void);' as strict C23 requires. (Problem reported by Houge Langley.) + The code's functions now constrain their arguments with the C + 'restrict' keyword consistently with their documentation. + This may allow future optimizations. + Release 2022g - 2022-11-29 08:58:31 -0800 diff --git a/asctime.c b/asctime.c index c84fe8c..375c913 100644 --- a/asctime.c +++ b/asctime.c @@ -61,7 +61,7 @@ static char buf_ctime[sizeof buf_asctime]; #endif char * -asctime_r(register const struct tm *timeptr, char *buf) +asctime_r(struct tm const *restrict timeptr, char *restrict buf) { static const char wday_name[][4] = { "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" diff --git a/localtime.c b/localtime.c index f1a8598..9b5d0a5 100644 --- a/localtime.c +++ b/localtime.c @@ -1628,7 +1628,8 @@ localsub(struct state const *sp, time_t const *timep, int_fast32_t setname, #if NETBSD_INSPIRED struct tm * -localtime_rz(struct state *sp, time_t const *timep, struct tm *tmp) +localtime_rz(struct state *restrict sp, time_t const *restrict timep, + struct tm *restrict tmp) { return localsub(sp, timep, 0, tmp); } @@ -1660,7 +1661,7 @@ localtime(const time_t *timep) } struct tm * -localtime_r(const time_t *timep, struct tm *tmp) +localtime_r(const time_t *restrict timep, struct tm *restrict tmp) { return localtime_tzset(timep, tmp, false); } @@ -1693,7 +1694,7 @@ gmtsub(ATTRIBUTE_MAYBE_UNUSED struct state const *sp, time_t const *timep, */ struct tm * -gmtime_r(const time_t *timep, struct tm *tmp) +gmtime_r(time_t const *restrict timep, struct tm *restrict tmp) { gmtcheck(); return gmtsub(gmtptr, timep, 0, tmp); @@ -2297,7 +2298,7 @@ mktime_tzname(struct state *sp, struct tm *tmp, bool setname) #if NETBSD_INSPIRED time_t -mktime_z(struct state *sp, struct tm *tmp) +mktime_z(struct state *restrict sp, struct tm *restrict tmp) { return mktime_tzname(sp, tmp, false); } diff --git a/private.h b/private.h index 7ddf4e5..5043cb8 100644 --- a/private.h +++ b/private.h @@ -920,7 +920,7 @@ static_assert(! TYPE_SIGNED(time_t) || ! SIGNED_PADDING_CHECK_NEEDED #if HAVE_INCOMPATIBLE_CTIME_R #undef asctime_r #undef ctime_r -char *asctime_r(struct tm const *, char *); +char *asctime_r(struct tm const *restrict, char *restrict); char *ctime_r(time_t const *, char *); #endif /* HAVE_INCOMPATIBLE_CTIME_R */ diff --git a/strftime.c b/strftime.c index b23b610..df16983 100644 --- a/strftime.c +++ b/strftime.c @@ -116,7 +116,8 @@ static char * _yconv(int, int, bool, bool, char *, char const *); #if HAVE_STRFTIME_L size_t -strftime_l(char *s, size_t maxsize, char const *format, struct tm const *t, +strftime_l(char *restrict s, size_t maxsize, char const *restrict format, + struct tm const *restrict t, ATTRIBUTE_MAYBE_UNUSED locale_t locale) { /* Just call strftime, as only the C locale is supported. */ @@ -125,7 +126,8 @@ strftime_l(char *s, size_t maxsize, char const *format, struct tm const *t, #endif size_t -strftime(char *s, size_t maxsize, const char *format, const struct tm *t) +strftime(char *restrict s, size_t maxsize, char const *restrict format, + struct tm const *restrict t) { char * p; int saved_errno = errno; -- 2.38.1

1 0

Confusing zdump output for America/Ojinaga
by Dave Rolsky Dec. 14, 2022

Dec. 14, 2022

I'm a bit confused regarding the output from zdump for the new America/Ojinaga zone. Here's the output for 2022: America/Ojinaga Sun Mar 13 08:59:59 2022 UT = Sun Mar 13 01:59:59 2022 MST isdst=0 gmtoff=-25200 America/Ojinaga Sun Mar 13 09:00:00 2022 UT = Sun Mar 13 03:00:00 2022 MDT isdst=1 gmtoff=-21600 America/Ojinaga Sun Oct 30 07:59:59 2022 UT = Sun Oct 30 01:59:59 2022 MDT isdst=1 gmtoff=-21600 America/Ojinaga Sun Oct 30 08:00:00 2022 UT = Sun Oct 30 03:00:00 2022 CDT isdst=1 gmtoff=-18000 America/Ojinaga Sun Nov 6 06:59:59 2022 UT = Sun Nov 6 01:59:59 2022 CDT isdst=1 gmtoff=-18000 America/Ojinaga Sun Nov 6 07:00:00 2022 UT = Sun Nov 6 01:00:00 2022 CST isdst=0 gmtoff=-21600 Note that there's no November 30 event. But based on the zone's definition I'd expect to see these events: Oct 30 - change to _CST_ Nov 30 - No change, I guess, since the change to the US rules on Nov 30 doesn't actually change the offset or isdst flag. But maybe I'm misunderstanding how to interpret the zone file definition? Cheers, Dave Rolsky http://blog.urth.org https://github.com/autarch

3 4

[PATCH v2 1/4] zic.8: Add public domain notice
by Alejandro Colomar Dec. 13, 2022

Dec. 13, 2022

Signed-off-by: Alejandro Colomar <alx(a)kernel.org> --- Hi Paul, v2: - This time I sent them to the tz mailing list too (and also linux-man@). - Added ACK and review from Branden in 3/4 and 4/4. - Added comment from Branden to commit message in 4/4. - Added tweak suggested by Branden in 3/4. zic.8 | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/zic.8 b/zic.8 index f79148f4..c2c61739 100644 --- a/zic.8 +++ b/zic.8 @@ -1,3 +1,7 @@ +.\" %%%LICENSE_START(PUBLIC_DOMAIN) +.\" This page is in the public domain +.\" %%%LICENSE_END +.\" .TH ZIC 8 .SH NAME zic \- timezone compiler -- 2.38.1

3 18

Single source of truth for timezone data
by Benjamin Drung Dec. 11, 2022

Dec. 11, 2022

Hi everyone, I am writing this mail with my distribution maintainer hat on since I am responsible for keeping the tzdata package up-to-date in Ubuntu. I like to propose to have a single source of truth for timezone data, which should be the tzdata source package. Updating this package in a distribution like Debian/Ubuntu should be enough to update all consumers in the distribution. Sadly this is currently not the case. Ubuntu since 20.04 (focal) adds the four icu source files metaZones.txt, timezoneTypes.txt, windowsZones.txt, and zoneinfo64.txt from https://github.com/unicode-org/icu-data to the tzdata source package. Then it uses genrb and icupkg to generate the .res files. Since the icu project lacks behind the tzdata release by hours up to days, Ubuntu has to update tzdata twice (first the tzdata release, then the icu update). metaZones.txt, timezoneTypes.txt, and windowsZones.txt are generated using tools/cldr/cldr-to-icu/build-icu-data.xml from https://github.com/unicode-org/icu. zoneinfo64.txt is generated by tz2icu. build-icu-data.xml uses https://github.com/unicode-org/cldr as input to convert the cldr data to icu. If I saw that correctly, only common/supplemental/metaZones.xml needs to be updated there on an update. Can tzdata include the necessary data and tools to generate metaZones.xml from its source? Then it would be possible to generate the icu data from the tzdata source without the need to wait for icu to catch up. Then Debian/Ubuntu can ship a tzdata-icu package for it [1]. [1] https://bugs.debian.org/954112 -- Benjamin Drung Debian & Ubuntu Developer

9 23

Error in America/Ojinaga
by Nikos (Nikolaos) Papadakos, PhD Dec. 10, 2022

Dec. 10, 2022

Hello, We are suspecting that your timezone update tzdb 2022g is incorrectly accounting for America/Ojinaga. Our customer is a major airline in Mexico and they tell me the time should America/Ojinaga should be the same as America/Denver. They provide as evidence official announcements in Spanish language. For example: https://www.dof.gob.mx/nota_detalle.php?codigo=5672650&fecha=29/11/2022#gsc… which says: "Artículo 5. III. Para el Estado de Baja California, así como para los municipios de Janos, Ascensión, Juárez, Praxedis G. Guerrero y Guadalupe, del Estado de Chihuahua, acorde a sus correlativos a su franja fronteriza, se aplica el meridiano 105 grados al oeste de Greenwich." I don't speak Spanish to be honest, my customer does. In the above the phrase seems to be "Juárez [...] del Estado de Chihuahua" which isreferring specifically to Ciudad Juárez in the State of Chihuahua. And then it says "el meridiano 105 grados al oeste de Greenwich" giving the degrees from Greenwich. They've given me some other references, but the above seems the most official. I would like to ask you to please double check which one is the correct. Best regards, Nikos P.S.: Please do not use my name or my company's name.

2 2

Re: [tz] Error in America/Ojinaga
by Brian Inglis Dec. 10, 2022

Dec. 10, 2022

On 2022-12-09 15:11, Tim Parenti via tz wrote: > On Fri, 9 Dec 2022 at 16:46, Nikos (Nikolaos) Papadakos, PhD wrote: >> Our customer is a major airline in Mexico and they tell me the time >> should America/Ojinaga should be the same as America/Denver. > It is our understanding that the recent changes split time zone observances > along Chihuahua's northern border. According to that split, from 2022-11-30, > Ojinaga is like America/Chicago, while Ciudad Juárez is like America/Denver. >> III. Para el Estado de Baja California, así como para los municipios >> de Janos, Ascensión, Juárez, Praxedis G. Guerrero y Guadalupe, del >> Estado de Chihuahua, acorde a sus correlativos a su franja fronteriza, >> se aplica el meridiano 105 grados al oeste de Greenwich." > While the above describes that the municipio of Juárez (including its municipal > seat, Ciudad Juárez) observes a standard time of UTC-7, which is like > America/Denver, the section immediately prior reads: > II. Para los municipios de Coyame del Sotol, Ojinaga y Manuel Benavides, > del Estado de Chihuahua, acorde a sus correlativos a su franja fronteriza, > se aplica el meridiano 90 grados al oeste de Greenwich; > …meaning that the city and municipio of Ojinaga follow UTC-6, which is like > America/Chicago. > A new zone, America/Ciudad_Juarez, was split off from America/Ojinaga in 2022g > to allow for these differences in timekeeping. Since this zone did not exist > prior to 2022g, those in the western portions of Chihuahua's border region > (including Juárez) will need to switch to it, as the time in and around Juárez > and Chihuahua's northwest no longer matches the time in Ojinaga and Chihuahua's > northeast. Nor the time in Chihuahua's interior which is on CST like Ojinaga. The airline can check the IATA SSIM Schedule Time Zones for CUU/MMC Chihuahua and CJS/MMCS Ciudad Juarez to confirm the changes (Ojinaga has no airport). -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

1 0

Re: [tz] Single source of truth for timezone data
by Brian Inglis Dec. 9, 2022

Dec. 9, 2022

On 2022-12-08 13:50, Paul Eggert via tz wrote: > On 2022-12-08 05:24, Almaz Mingaleev wrote: >>>> new timezone abbreviation "XYT", downstream distros like Ubuntu can >>>> immediately ship the new P without waiting for i18n updates. P will >> It is not a problem if a distro ships it, it is a problem if this new >> stuff leaks to the external world. > Sorry, I'm not following. When Ubuntu ships a new tzdata package then surely > that has "leaked" to the outside world? >> It would be naive to expect from a user base of a service to have >> up-to-date time zone data even after a month after TZDB release. > In the past I've gotten my Ubuntu systems updated within 24 hours of a tzdata > release, simply by applying patches as usual from Ubuntu. But as Benjamin > indicates, this is not happening with 2022g. I just now checked for updates and > I'm still stuck on 2022f. So from my point of view, Ubuntu is slow in this case > - instead of taking less than a day, it's taking more than a week. >> being consistently wrong about _new_ changes is better >> than having different answers within the platform. > As a Ubuntu user, I'd prefer tzdata to be up-to-date even though ICU is > out-of-date, over having both tzdata and ICU out-of-date. Of course Ubuntu > differs from Android in that most apps use tzdata not ICU. Still, I'm a bit > curious what end-user-visible problems would occur on Android and/or Ubuntu if > tzdata leads ICU slightly. I know you've seen problems, but were they end-user > problems or just test-case problems? On Ubuntu various other copies of tzdata > (e.g., Python's) can be slightly out of date too, but this doesn't seem to be > much of an issue. >> It is not translations that we are waiting for, but changes like [1 >> <https://github.com/unicode-org/icu/pull/2261/files>]. Recent time zone >> changes were short notice ones and ICU team (thanks Yoshito and others!) >> did these changes very quickly. > Thanks, I didn't know that. > Here's a timeline I see for the latest Mexico change: > * 2022-11-28 17:00 UTC - news article published announcing the change (which is > not official yet, I think) > <http://puentelibre.mx/noticia/ciudad_juarez_cambio_horario_noviembre_2022/> > * 2022-11-29 03:55:31 UTC - tz mailing list notified > <https://mm.icann.org/pipermail/tz/2022-November/032365.html> > * 2022-11-29 17:42:29 UTC (14 hours after notification) - tzdb 2022g announced > <https://mm.icann.org/pipermail/tz-announce/2022-November/000076.html> > * 2022-11-29 18:23:41 UTC (less than an hour after tzdb 2022g announcement) > tzdata 2022g-r0 released for Alpine Linux > <https://pkgs.alpinelinux.org/package/edge/main/x86/tzdata> > * 2022-11-30 07:06 UTC (7 hours after tzdb 2022g announcement) - tzdata 2022g-1 > released for Arch Linux <https://archlinux.org/packages/core/x86_64/tzdata/> > * 2022-12-01 03:08:08 UTC (33 hours after tzdb 2022g announcement) - > abovementioned ICU patch committed > * 2022-12-01 12:38:06 UTC (9 hours after ICU patch committed) - Ubuntu patch > committed <https://launchpad.net/ubuntu/+source/tzdata/2022g-0ubuntu0.22.10.1> > * 2022-12-05 (4 days after ICU patch committed) - Red Hat Enterprise Linux fix > available to users <https://access.redhat.com/errata/RHBA-2022:8785> > * 2022-12-07 (6 days after ICU patch committed) - Android patch committed > <https://android.googlesource.com/platform/system/timezone/+/ea3e0ece71974c1…> > * now (a week after ICU patch committed) - my Ubuntu workstation is still not > updated. > We should be able to do better than this; that is, be more like Alpine or Arch > Linux, or at least more like RHEL (though I see that Fedora still hasn't > released 2022g...). Though ICU is part of the problem (as is tzdb itself :-), > most of the delay seems to be occurring even after ICU patches are applied. Launchpad shows Ubuntu 22.10 Proposed kinetic-proposed/main tzdata 2022g, also jammy- and focal-proposed, released Dec 1 when the maintainer started this thread. You could add the -proposed source to apt sources, and/or set apt preferences to only use it for tzdata, as the -proposed source seems to be first to get ICU updates in tzdata package release yyyyX-0ubuntu0.MM.mm.1; -updates and -security follow. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

1 0

[PROPOSED] America/Yellowknife now links to America/Edmonton
by Paul Eggert Dec. 9, 2022

Dec. 9, 2022

(Thanks to Almaz Mingaleev.) * NEWS: Mention this. * backzone (America/Yellowknife): Move Zone here ... * northamerica: ... from here. * zone.tab, zone1970.tab: Remove America/Yellowknife. --- NEWS | 8 ++++++++ backzone | 5 +++++ northamerica | 7 ------- zone.tab | 3 +-- zone1970.tab | 3 +-- 5 files changed, 15 insertions(+), 11 deletions(-) diff --git a/NEWS b/NEWS index ac0b611a..98cc14f7 100644 --- a/NEWS +++ b/NEWS @@ -4,6 +4,7 @@ Unreleased, experimental changes Briefly: Much of Greenland still uses DST from 2024 on. + America/Yellowknife now links to America/Edmonton. The code now defaults to C99 or later. Fix use of C23 attributes. @@ -17,6 +18,13 @@ Unreleased, experimental changes This change from 2022g doesn't affect timestamps until 2024-03-30, and doesn't affect tm_isdst until 2023-03-25. + Changes to past timestamps + + America/Yellowknife has changed from a Zone to a backward + compatibility Link, as it no longer differs from America/Edmonton + since 1970. (Thanks to Almaz Mingaleev.) This affects some + pre-1948 timestamps. The old data are now in 'backzone'. + Changes to code The code by default is now designed for C99 or later. To build in diff --git a/backzone b/backzone index 7803c57d..1bd23ac6 100644 --- a/backzone +++ b/backzone @@ -928,6 +928,11 @@ Zone America/Thunder_Bay -5:57:00 - LMT 1895 Zone America/Tortola -4:18:28 - LMT 1911 Jul # Road Town -4:00 - AST +# Yellowknife, Northwest Territories +Zone America/Yellowknife 0 - -00 1935 # Yellowknife founded? + -7:00 NT_YK M%sT 1980 + -7:00 Canada M%sT + # Dumont d'Urville, Île des Pétrels, -6640+14001, since 1956-11 # <https://en.wikipedia.org/wiki/Dumont_d'Urville_Station> (2005-12-05) # diff --git a/northamerica b/northamerica index e33701bf..24b68e72 100644 --- a/northamerica +++ b/northamerica @@ -2125,10 +2125,6 @@ Zone America/Fort_Nelson -8:10:47 - LMT 1884 # Nunavut ... moved ... to incorporate the whole territory into one time zone. # Nunavut moves to single time zone Oct. 31 # http://www.nunatsiaq.com/nunavut/nvt90903_13.html -# -# From Antoine Leca (1999-09-06): -# We then need to create a new timezone for the Kitikmeot region of Nunavut -# to differentiate it from the Yellowknife region. # From Paul Eggert (1999-09-20): # Basic Facts: The New Territory @@ -2322,9 +2318,6 @@ Zone America/Cambridge_Bay 0 - -00 1920 # trading post est.? -5:00 - EST 2000 Nov 5 0:00 -6:00 - CST 2001 Apr 1 3:00 -7:00 Canada M%sT -Zone America/Yellowknife 0 - -00 1935 # Yellowknife founded? - -7:00 NT_YK M%sT 1980 - -7:00 Canada M%sT Zone America/Inuvik 0 - -00 1953 # Inuvik founded -8:00 NT_YK P%sT 1979 Apr lastSun 2:00 -7:00 NT_YK M%sT 1980 diff --git a/zone.tab b/zone.tab index 6e5adb9f..5d5c79ff 100644 --- a/zone.tab +++ b/zone.tab @@ -121,9 +121,8 @@ CA +744144-0944945 America/Resolute Central - NU (Resolute) CA +624900-0920459 America/Rankin_Inlet Central - NU (central) CA +5024-10439 America/Regina CST - SK (most areas) CA +5017-10750 America/Swift_Current CST - SK (midwest) -CA +5333-11328 America/Edmonton Mountain - AB; BC (E); SK (W) +CA +5333-11328 America/Edmonton Mountain - AB; BC (E); NT (E); SK (W) CA +690650-1050310 America/Cambridge_Bay Mountain - NU (west) -CA +6227-11421 America/Yellowknife Mountain - NT (central) CA +682059-1334300 America/Inuvik Mountain - NT (west) CA +4906-11631 America/Creston MST - BC (Creston) CA +5546-12014 America/Dawson_Creek MST - BC (Dawson Cr, Ft St John) diff --git a/zone1970.tab b/zone1970.tab index a9b36d36..819316be 100644 --- a/zone1970.tab +++ b/zone1970.tab @@ -108,9 +108,8 @@ CA +744144-0944945 America/Resolute Central - NU (Resolute) CA +624900-0920459 America/Rankin_Inlet Central - NU (central) CA +5024-10439 America/Regina CST - SK (most areas) CA +5017-10750 America/Swift_Current CST - SK (midwest) -CA +5333-11328 America/Edmonton Mountain - AB; BC (E); SK (W) +CA +5333-11328 America/Edmonton Mountain - AB; BC (E); NT (E); SK (W) CA +690650-1050310 America/Cambridge_Bay Mountain - NU (west) -CA +6227-11421 America/Yellowknife Mountain - NT (central) CA +682059-1334300 America/Inuvik Mountain - NT (west) CA +5546-12014 America/Dawson_Creek MST - BC (Dawson Cr, Ft St John) CA +5848-12242 America/Fort_Nelson MST - BC (Ft Nelson) -- 2.37.2

2 2

[PROPOSED] Try to check longstanding padding assumptions
by Paul Eggert Dec. 8, 2022

Dec. 8, 2022

This is helpful only when porting to oddball platforms in some situations where time_t is signed and has padding bits. (Even C23 allows these platforms.) Formerly tzcode would silently have undefined runtime behavior on such platforms; with this patch, there is likely a compile-time diagnostic instead. * private.h (static_assert): New macro, defined for pre-C23 compilers. (SIGNED_PADDING_CHECK_NEEDED): New constant. Try to check that TIME_T_MIN and TIME_T_MAX are actually the min and max time_t values. --- private.h | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/private.h b/private.h index 1d6ddf7..7ddf4e5 100644 --- a/private.h +++ b/private.h @@ -43,6 +43,10 @@ # include <stdbool.h> #endif +#if __STDC_VERSION__ < 202311 +# define static_assert(cond) extern int static_assert_check[(cond) ? 1 : -1] +#endif + /* ** zdump has been made independent of the rest of the time ** conversion package to increase confidence in the verification it provides. @@ -833,10 +837,23 @@ ATTRIBUTE_REPRODUCIBLE time_t time2posix_z(timezone_t, time_t); int: INT_MAX, long: LONG_MAX, long long: LLONG_MAX, \ default: TIME_T_MAX_NO_PADDING) \ : (time_t) -1) +enum { SIGNED_PADDING_CHECK_NEEDED + = _Generic((time_t) 0, + signed char: false, short: false, + int: false, long: false, long long: false, + default: true) }; #else # define TIME_T_MIN TIME_T_MIN_NO_PADDING # define TIME_T_MAX TIME_T_MAX_NO_PADDING -#endif +enum { SIGNED_PADDING_CHECK_NEEDED = true }; +#endif +/* Try to check the padding assumptions. Although TIME_T_MAX and the + following check can both have undefined behavior on oddball + platforms due to shifts exceeding widths of signed integers, these + platforms' compilers are likely to diagnose these issues in integer + constant expressions, so it shouldn't hurt to check statically. */ +static_assert(! TYPE_SIGNED(time_t) || ! SIGNED_PADDING_CHECK_NEEDED + || TIME_T_MAX >> (TYPE_BIT(time_t) - 2) == 1); /* ** 302 / 1000 is log10(2.0) rounded up. -- 2.38.1

1 0

[PROPOSED] Update city lists in theory.html
by Paul Eggert Dec. 7, 2022

Dec. 7, 2022

* theory.html: Update xMT city lists to match what’s currently generated by the default build. --- theory.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/theory.html b/theory.html index 6a39ce7a..fbbb9e47 100644 --- a/theory.html +++ b/theory.html @@ -494,7 +494,7 @@ in decreasing order of importance: <p> <small>These abbreviations are: AMT Asunción, Athens; - BMT Baghdad, Bangkok, Batavia, Bermuda, Bern, Bogotá, Bridgetown, + BMT Baghdad, Bangkok, Batavia, Bermuda, Bern, Bogotá, Brussels, Bucharest; CMT Calamarca, Caracas, Chisinau, Colón, Córdoba; DMT Dublin/Dunsink; @@ -506,7 +506,7 @@ in decreasing order of importance: IMT Irkutsk, Istanbul; JMT Jerusalem; KMT Kaunas, Kyiv, Kingston; - LMT Lima, Lisbon, local, Luanda; + LMT Lima, Lisbon, local; MMT Macassar, Madras, Malé, Managua, Minsk, Monrovia, Montevideo, Moratuwa, Moscow; PLMT Phù Liễn; -- 2.37.2

1 0

[PATCH] Update abbreviation lists in theory.html
by Paul Eggert Dec. 7, 2022

Dec. 7, 2022

* theory.html: Update abbreviation lists to match what’s currently generated by the default build. --- theory.html | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/theory.html b/theory.html index f2b798be..6a39ce7a 100644 --- a/theory.html +++ b/theory.html @@ -443,11 +443,11 @@ in decreasing order of importance: CAT/CAST Central Africa, CET/CEST/CEMT Central European, ChST Chamorro, - CST/CDT/CWT/CPT/CDDT Central [North America], + CST/CDT/CWT/CPT Central [North America], CST/CDT China, GMT/BST/IST/BDST Greenwich, EAT East Africa, - EST/EDT/EWT/EPT/EDDT Eastern [North America], + EST/EDT/EWT/EPT Eastern [North America], EET/EEST Eastern European, GST/GDT Guam, HST/HDT/HWT/HPT Hawaii, @@ -460,13 +460,13 @@ in decreasing order of importance: MET/MEST Middle European (a backward-compatibility alias for Central European), MSK/MSD Moscow, - MST/MDT/MWT/MPT/MDDT Mountain, + MST/MDT/MWT/MPT Mountain, NST/NDT/NWT/NPT/NDDT Newfoundland, NST/NDT/NWT/NPT Nome, NZMT/NZST New Zealand through 1945, NZST/NZDT New Zealand 1946–present, PKT/PKST Pakistan, - PST/PDT/PWT/PPT/PDDT Pacific, + PST/PDT/PWT/PPT Pacific, PST/PDT Philippine, SAST South Africa, SST Samoa, @@ -512,6 +512,7 @@ in decreasing order of importance: PLMT Phù Liễn; PMT Paramaribo, Paris, Perm, Pontianak, Prague; PMMT Port Moresby; + PPMT Port-au-Prince; QMT Quito; RMT Rangoon, Riga, Rome; SDMT Santo Domingo; @@ -519,8 +520,7 @@ in decreasing order of importance: SMT Santiago, Simferopol, Singapore, Stanley; TBMT Tbilisi; TMT Tallinn, Tehran; - WMT Warsaw; - ZMT Zomba.</small> + WMT Warsaw.</small> </p> <p> -- 2.37.2

1 0

Re: [tz] TZDB patches, UTF-8, and Microsoft Exchange
by Brian Inglis Dec. 4, 2022

Dec. 4, 2022

On 2022-12-04 12:48, Fred Gleason via tz wrote: > On Dec 2, 2022, at 17:21, Derick Rethans via tz <tz(a)iana.org > <mailto:tz@iana.org>> wrote: > >> This problem would go away if you'd except change requests through GitHub's >> pull request feature. > > I for one heartily second this suggestion. While I understand that this can be a > sensitive issue for some long-time contributors here, given the composition of > TZDB’s audience (veteran coders plus the occasional technically > non-sophisticated user), I think anything that simplifies the overall workflow > while making the process more transparent to non-coders would be a net win. > > >> It's quite a common and modern method to propose changes to open source >> software, that I'd expect many would already be familiar with. > > I agree. The GitHub pull request process has become a sort of _lingua franca_ in > the code development realm, arguably more so than any other single methodology > for managing distributed open source development. In that context, the current > _status quo_ is rather *anti*-user friendly in the sense that many coders, when > first encountering the TZDB GitHub repo think that they already know how to > generate and submit patches; only later discovering that they in fact don’t, > since what is arguably the central workflow metaphor of what makes GitHub useful > has (seemingly inexplicably) been switched off. > > On the basis of the patches I’ve seen go by on this listserv over the past few > years, it would also seem that “easing/reducing maintenance burden” has become a > major goal for TZDB. Given that, I would respectfully argue that moving to a > PR-based workflow would do more towards that end than any number of minor code > polishing changes. > > > On Dec 2, 2022, at 17:43, Paul Eggert via tz <tz(a)iana.org <mailto:tz@iana.org>> > wrote: > >> Yes, but GitHub has its own problems. I'd rather stick with email, just as >> many other projects use email for this sort of thing. > > Well, this one at least does. FWIW, none of the other FOSS projects whose dev > lists I follow use the traditional patches-via-email workflow any more. While by > no means all of them use GitHub, what they all do use is some sort of system > that provides automated patch generation/testing/merging along with a GUI option > that allows non-coder types some level of visibility into the process. > > >> Also, I've been thinking of moving the development repository off GitHub for >> other reasons, and I don't want to rely on GitHub-specific features. > > Would you care to share with us what some of those “other reasons” might be? At a guess, I'd imagine for a multi-GNU project contributor, even using a proprietary vendor locked-in (and potentially future deprecated or locked-out) platform might be an issue (possibly queried only in person or private DM), as it is for many other open source contributors, where even mentioning GitHub evokes a spit-blah *NEVER* response, and moving to GH would result in losing some contributions. For some open-source projects, GH is used only as a public and backup repo for their primary dev workflows, as are sv.gnu.org and sv.non-gnu.org in some cases. A number are using in-house and/or public GitLab instances, and others have surfaced their email with public-inbox like https://lore.kernel.org/ where issues and patches can be handled using workflow tools like https://git.kernel.org/pub/scm/utils/b4/b4.git It would be good if the IETF, IANA, and/or ICANN made their email available in such searchable archives, an area where tz is currently lacking. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

1 0

[PATCH] Fix America/Nuuk timezone change
by Thomas M. Steenholdt Dec. 4, 2022

Dec. 4, 2022

Fix the upcoming move of America/Nuuk from normaltime -03 to -02, according to the passed bill. --- europe | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/europe b/europe index a3547b4f..71ea3ab2 100644 --- a/europe +++ b/europe @@ -1126,6 +1126,21 @@ Zone Atlantic/Faroe -0:27:04 - LMT 1908 Jan 11 # Tórshavn # "bekymringer" URL says the intent is no transition March 25, that # Greenland will not go back to winter time in fall 2023, and that # only America/Nuuk is affected (though further changes may occur). +# +# From Thomas M. Steenholdt (2022-12-02): +# Processing of the bill is documented here: +# https://ina.gl/samlinger/oversigt-over-samlinger/samling/dagsordener/dagsor… +# Notably: +# - The bill to move America/Nuuk from UTC-03 to UTC-02 passed. +# - The bill to stop observing DST did not (Greenland will stop observing DST +# when EU does). +# Details on the implementation are here (section 6): +# https://ina.gl/dvd/EM%202022/pdf/media/2553529/pkt17_em2022_tidens_bestemme… +# This is how the change will be implemented: +# 1. The shift *to* DST in 2023 happens as normal. +# 2. The shift *from* DST in 2023 happens as normal, but coincides with the +# shift to UTC-02 normaltime (people will not change their clocks here). +# 3. After this, DST is still observed, but as -02/-01 instead of -03/-02. # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule Thule 1991 1992 - Mar lastSun 2:00 1:00 D @@ -1149,8 +1164,8 @@ Zone America/Scoresbysund -1:27:52 - LMT 1916 Jul 28 # Ittoqqortoormiit -1:00 EU -01/+00 Zone America/Nuuk -3:26:56 - LMT 1916 Jul 28 # Godthåb -3:00 - -03 1980 Apr 6 2:00 - -3:00 EU -03/-02 2023 Mar 25 22:00 - -2:00 - -02 + -3:00 EU -03/-02 2023 Oct 28 23:00 + -2:00 EU -02/-01 Zone America/Thule -4:35:08 - LMT 1916 Jul 28 # Pituffik -4:00 Thule A%sT -- 2.34.1

5 7

[PROPOSED] Default to assuming C99 or later
by Paul Eggert Dec. 2, 2022

Dec. 2, 2022

By default, assume the compiler and library support C99 or later. Continue to port to C89 platforms only if the new macro PORT_TO_C89 is nonzero. This new macro is a transitional aid, and is planned to be removed in a future version that always assumes C99 or later. * Makefile, NEWS: Mention this. * private.h (PORT_TO_C89): New macro. (SUPPORT_C89): Move up. (true, false, bool) [!PORT_TO_C89]: Assume C99 or later. If !PORT_TO_C89 simply include <inttypes.h> rather than fooling around with conditional stdint.h, conditional inttypes.h, and lots of other conditional definitions. (restrict) [!PORT_TO_C89]: Do not define. * zdump.c (HAVE_SNPRINTF) [!PORT_TO_C89]: Now true. --- Makefile | 14 ++++++++------ NEWS | 11 ++++++----- private.h | 35 +++++++++++++++++++++++++---------- zdump.c | 2 +- 4 files changed, 40 insertions(+), 22 deletions(-) diff --git a/Makefile b/Makefile index 63f3b5ca..8bee50d8 100644 --- a/Makefile +++ b/Makefile @@ -220,7 +220,7 @@ LDLIBS= # -DHAVE_INCOMPATIBLE_CTIME_R if your system's time.h declares # ctime_r and asctime_r incompatibly with the POSIX standard # (Solaris when _POSIX_PTHREAD_SEMANTICS is not defined). -# -DHAVE_INTTYPES_H=0 if <inttypes.h> does not work* +# -DHAVE_INTTYPES_H=0 if <inttypes.h> does not work*+ # -DHAVE_LINK=0 if your system lacks a link function # -DHAVE_LOCALTIME_R=0 if your system lacks a localtime_r function # -DHAVE_LOCALTIME_RZ=0 if you do not want zdump to use localtime_rz @@ -229,24 +229,24 @@ LDLIBS= # -DHAVE_POSIX_DECLS=0 if your system's include files do not declare # functions like 'link' or variables like 'tzname' required by POSIX # -DHAVE_SETENV=0 if your system lacks the setenv function -# -DHAVE_SNPRINTF=0 if your system lacks the snprintf function +# -DHAVE_SNPRINTF=0 if your system lacks the snprintf function+ # -DHAVE_STDCKDINT_H=0 if neither <stdckdint.h> nor substitutes like # __builtin_add_overflow work* -# -DHAVE_STDINT_H=0 if <stdint.h> does not work* +# -DHAVE_STDINT_H=0 if <stdint.h> does not work*+ # -DHAVE_STRFTIME_L if <time.h> declares locale_t and strftime_l # -DHAVE_STRDUP=0 if your system lacks the strdup function -# -DHAVE_STRTOLL=0 if your system lacks the strtoll function +# -DHAVE_STRTOLL=0 if your system lacks the strtoll function+ # -DHAVE_SYMLINK=0 if your system lacks the symlink function # -DHAVE_SYS_STAT_H=0 if <sys/stat.h> does not work* # -DHAVE_TZSET=0 if your system lacks a tzset function # -DHAVE_UNISTD_H=0 if <unistd.h> does not work* # -DHAVE_UTMPX_H=0 if <utmpx.h> does not work* # -Dlocale_t=XXX if your system uses XXX instead of locale_t +# -DPORT_TO_C89 if tzcode should also run on C89 platforms+ # -DRESERVE_STD_EXT_IDS if your platform reserves standard identifiers # with external linkage, e.g., applications cannot define 'localtime'. # -Dssize_t=long on hosts like MS-Windows that lack ssize_t -# -DSUPPORT_C89 if you build or run tzcode on a C89 platform; this option -# is obsolescent and is planned to be removed when C99+ is required. +# -DSUPPORT_C89 if the tzcode library should support C89 callers+ # -DSUPPRESS_TZDIR to not prepend TZDIR to file names; this has # security implications and is not recommended for general use # -DTHREAD_SAFE to make localtime.c thread-safe, as POSIX requires; @@ -275,6 +275,8 @@ LDLIBS= # $(GCC_DEBUG_FLAGS) if you are using recent GCC and want lots of checking # # * Options marked "*" can be omitted if your compiler is C23 compatible. +# * Options marked "+" are obsolescent and are planned to be removed +# once the code assumes C99 or later. # # Select instrumentation via "make GCC_INSTRUMENT='whatever'". GCC_INSTRUMENT = \ diff --git a/NEWS b/NEWS index 25dcc875..91ec5056 100644 --- a/NEWS +++ b/NEWS @@ -3,15 +3,16 @@ News for the tz database Unreleased, experimental changes Briefly: - tzcode no longer supports C89 unless built with -DSUPPORT_C89 + The code now defaults to C99 or later. Fix use of C23 attributes. Changes to code - tzcode no longer supports C89 by default. To build or run in a - C89 environment, compile with -DSUPPORT_C89, a transitional aid - that is planned to be removed in a near-future version, when C99 - or later will be required. + The code by default is now designed for C99 or later. To build in + a C89 environment, compile with -DPORT_TO_C89. To support C89 + callers of the tzcode library, compile with -DSUPPORT_C89. The + two new macros are transitional aids planned to be removed in a + future version, when C99 or later will be required. On C23-compatible platforms tzcode no longer uses syntax like 'static [[noreturn]] void usage(void);'. Instead, it uses diff --git a/private.h b/private.h index 999c1648..1d6ddf73 100644 --- a/private.h +++ b/private.h @@ -17,12 +17,25 @@ ** Thank you! */ +/* PORT_TO_C89 means the code should work even if the underlying + compiler and library support only C89. SUPPORT_C89 means the + tzcode library should support C89 callers in addition to the usual + support for C99-and-later callers. These macros are obsolescent, + and the plan is to remove them along with any code needed only when + they are nonzero. */ +#ifndef PORT_TO_C89 +# define PORT_TO_C89 0 +#endif +#ifndef SUPPORT_C89 +# define SUPPORT_C89 0 +#endif + #ifndef __STDC_VERSION__ # define __STDC_VERSION__ 0 #endif /* Define true, false and bool if they don't work out of the box. */ -#if __STDC_VERSION__ < 199901 +#if PORT_TO_C89 && __STDC_VERSION__ < 199901 # define true 1 # define false 0 # define bool int @@ -100,10 +113,6 @@ # define HAVE_STRDUP 1 #endif -#ifndef HAVE_STRTOLL -# define HAVE_STRTOLL 1 -#endif - #ifndef HAVE_SYMLINK # define HAVE_SYMLINK 1 #endif /* !defined HAVE_SYMLINK */ @@ -185,6 +194,9 @@ #include <stddef.h> #include <string.h> +#if !PORT_TO_C89 +# include <inttypes.h> +#endif #include <limits.h> /* for CHAR_BIT et al. */ #include <stdlib.h> @@ -254,6 +266,8 @@ # define R_OK 4 #endif /* !defined R_OK */ +#if PORT_TO_C89 + /* ** Define HAVE_STDINT_H's default value here, rather than at the ** start, since __GLIBC__ and INTMAX_MAX's values depend on @@ -334,6 +348,9 @@ typedef int int_fast32_t; #ifndef INTMAX_MAX # ifdef LLONG_MAX typedef long long intmax_t; +# ifndef HAVE_STRTOLL +# define HAVE_STRTOLL true +# endif # if HAVE_STRTOLL # define strtoimax strtoll # endif @@ -396,6 +413,8 @@ typedef unsigned long uintmax_t; # define SIZE_MAX ((size_t) -1) #endif +#endif /* PORT_TO_C89 */ + /* Support ckd_add, ckd_sub, ckd_mul on C23 or recent-enough GCC-like hosts, unless compiled with -DHAVE_STDCKDINT_H=0 or with pre-C23 EDG. */ #if !defined HAVE_STDCKDINT_H && defined __has_include @@ -520,7 +539,7 @@ typedef unsigned long uintmax_t; # endif #endif -#if __STDC_VERSION__ < 199901 && !defined restrict +#if PORT_TO_C89 && __STDC_VERSION__ < 199901 && !defined restrict # define restrict /* empty */ #endif @@ -704,10 +723,6 @@ extern int daylight; extern long altzone; #endif -#ifndef SUPPORT_C89 -# define SUPPORT_C89 0 -#endif - /* ** The STD_INSPIRED functions are similar, but most also need ** declarations if time_tz is defined. diff --git a/zdump.c b/zdump.c index bac4a67a..5173c9ac 100644 --- a/zdump.c +++ b/zdump.c @@ -15,7 +15,7 @@ #include <stdio.h> #ifndef HAVE_SNPRINTF -# define HAVE_SNPRINTF (199901 <= __STDC_VERSION__) +# define HAVE_SNPRINTF (!PORT_TO_C89 || 199901 <= __STDC_VERSION__) #endif #ifndef HAVE_LOCALTIME_R -- 2.37.2

1 0

[PROPOSED] Port alignof to Oracle Developer Studio
by Paul Eggert Dec. 2, 2022

Dec. 2, 2022

* zic.c (alignof): Don’t include <stdalign.h> when compiling with Oracle Developer Studio, as release 12.6 lacks <stdalign.h> even though it #defines __STDC_VERSION__ to 201112L. Most likely this circa-2017 release, which #defines __SUNPRO_C to be 0x5150, is the last release, so assume that all releases lack <stdalign.h>. --- zic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zic.c b/zic.c index f143fcef..5612805f 100644 --- a/zic.c +++ b/zic.c @@ -67,7 +67,7 @@ enum { FORMAT_LEN_GROWTH_BOUND = 5 }; #endif /* The minimum alignment of a type, for pre-C23 platforms. */ -#if __STDC_VERSION__ < 201112 +#if __STDC_VERSION__ < 201112 || defined __SUNPRO_C # define alignof(type) offsetof(struct { char a; type b; }, b) #elif __STDC_VERSION__ < 202311 # include <stdalign.h> -- 2.37.2

2 2

1981/2 Singapore+Malaysia switch from GMT+0730 to GMT+0800
by Robert Elz Dec. 1, 2022

Dec. 1, 2022

This press release was discovered, and brought up in another forum by Geoff Clare. It conflicts with the data in the Asia/Singapore and Asia/Kuala-Lumpur zones. https://corporate.nas.gov.sg/media/collections-and-research/time-zone-adjus… That puts the change as being from 23:29:59 Dec 31, 1981 -> 00:00:00 Jan 1, 1982 whereas tzdata (going back to quite ancient versions) has the transition 23:59:59 Dec 31, 1981 -> 00:30:00 Jan 1, 1982 The version from the web page makes more sense to me (as in that is how I would have done that transition) but that does not mean that it is necessarily correct. Nothing there shows a copy of the actual gazette notification by the President (of Singapore in that case, but I think we can safely assume that it was done the same as in Malaysia) which would be the actual specification, but that 2015 press release says it happened as described that it would happen in the 1981 press release which is included there. The "asia" file just says of this transition: 7:30 - +0730 1982 Jan 1 8:00 - +08 which is correct in a sense for either version of when the transition occurred, and perhaps raises a general question of when a step forward takes place at the boundary between two days, does it more often delete the last part of the previous day or the first part of the next? I can find nothing in my tz list archives that says anything at all about this transition - the earliest message with any specific content about Singapore I could see was a Jan 2004 message from Mok Ly Yng (forwarded to the list by ado@), but that's really about earlier transitions - this one was already in the data (just with SGT instead of +0730 and +08). There's also a long Sept 2014 discussion about a zdump bug that this particular transition, as defined by zic, revealed, and a shorter discussion about the SGT removal in Sept 2018 - but that's all I managed to find about Singapore. While not about the Singapore/Malaysia zones themselves, even older data that appears on the list (ie: looking at diffs patches, and updated zone files) shows that in 1996 this transition was believed to have happened in May 1982 (which seems to be from Shanks). That altered in Dec 2003, in a change described as: * Fix several Malaysia and Singapore entries before 1983. Among other things, they enjoyed 20-minute DST from 1933 to 1936, and we have more-accurate dates for WWII transitions. (Thanks to Mok Ly Yng for this info.) which notably does not mention the change moving from May 1982 -> 1 Jan 1982 but that change was made in that version. Nothing appears to have happened since. I suspect it would be correct to change the first of those lines to be 7:30 - +0730 23:30 1981 Dec 30 but I am no authority on that. kre

5 13

[PROPOSED] Fix C23-related conformance bug
by Paul Eggert Dec. 1, 2022

Dec. 1, 2022

Problem reported by Houge Langley for ‘gcc -std=gnu99’ in: https://bugs.gentoo.org/show_bug.cgi?id=883719 * NEWS: Mention this. * date.c, localtime.c, private.h, zdump.c, zic.c: Use ATTRIBUTE_* at the start of function declarations, not later (such as after the keyword ‘static’). This is required for strict conformance to C23. --- NEWS | 6 ++++++ date.c | 2 +- localtime.c | 4 ++-- private.h | 6 +++--- zdump.c | 12 ++++++------ zic.c | 34 +++++++++++++++++----------------- 6 files changed, 35 insertions(+), 29 deletions(-) diff --git a/NEWS b/NEWS index 9cb175e7..25dcc875 100644 --- a/NEWS +++ b/NEWS @@ -4,6 +4,7 @@ Unreleased, experimental changes Briefly: tzcode no longer supports C89 unless built with -DSUPPORT_C89 + Fix use of C23 attributes. Changes to code @@ -12,6 +13,11 @@ Unreleased, experimental changes that is planned to be removed in a near-future version, when C99 or later will be required. + On C23-compatible platforms tzcode no longer uses syntax like + 'static [[noreturn]] void usage(void);'. Instead, it uses + '[[noreturn]] static void usage(void);' as strict C23 requires. + (Problem reported by Houge Langley.) + Release 2022g - 2022-11-29 08:58:31 -0800 diff --git a/date.c b/date.c index 11c5e5fe..97df6ab0 100644 --- a/date.c +++ b/date.c @@ -42,7 +42,7 @@ static void display(const char *, time_t); static void dogmt(void); static void errensure(void); static void timeout(FILE *, const char *, const struct tm *); -static ATTRIBUTE_NORETURN void usage(void); +ATTRIBUTE_NORETURN static void usage(void); int main(const int argc, char *argv[]) diff --git a/localtime.c b/localtime.c index f8a0a6eb..f1a8598b 100644 --- a/localtime.c +++ b/localtime.c @@ -843,7 +843,7 @@ is_digit(char c) ** Return a pointer to that character. */ -static ATTRIBUTE_REPRODUCIBLE const char * +ATTRIBUTE_REPRODUCIBLE static const char * getzname(register const char *strp) { register char c; @@ -864,7 +864,7 @@ getzname(register const char *strp) ** We don't do any checking here; checking is done later in common-case code. */ -static ATTRIBUTE_REPRODUCIBLE const char * +ATTRIBUTE_REPRODUCIBLE static const char * getqzname(register const char *strp, const int delim) { register int c; diff --git a/private.h b/private.h index c22354ac..999c1648 100644 --- a/private.h +++ b/private.h @@ -646,7 +646,7 @@ DEPRECATED_IN_C23 char *asctime(struct tm const *); char *asctime_r(struct tm const *restrict, char *restrict); DEPRECATED_IN_C23 char *ctime(time_t const *); char *ctime_r(time_t const *, char *); -double difftime(time_t, time_t) ATTRIBUTE_UNSEQUENCED; +ATTRIBUTE_UNSEQUENCED double difftime(time_t, time_t); size_t strftime(char *restrict, size_t, char const *restrict, struct tm const *restrict); # if HAVE_STRFTIME_L @@ -765,10 +765,10 @@ timezone_t tzalloc(char const *); void tzfree(timezone_t); # if STD_INSPIRED # if TZ_TIME_T || !defined posix2time_z -time_t posix2time_z(timezone_t, time_t) ATTRIBUTE_REPRODUCIBLE; +ATTRIBUTE_REPRODUCIBLE time_t posix2time_z(timezone_t, time_t); # endif # if TZ_TIME_T || !defined time2posix_z -time_t time2posix_z(timezone_t, time_t) ATTRIBUTE_REPRODUCIBLE; +ATTRIBUTE_REPRODUCIBLE time_t time2posix_z(timezone_t, time_t); # endif # endif #endif diff --git a/zdump.c b/zdump.c index 04953dcf..bac4a67a 100644 --- a/zdump.c +++ b/zdump.c @@ -89,7 +89,7 @@ static bool warned; static bool errout; static char const *abbr(struct tm const *); -static intmax_t delta(struct tm *, struct tm *) ATTRIBUTE_REPRODUCIBLE; +ATTRIBUTE_REPRODUCIBLE static intmax_t delta(struct tm *, struct tm *); static void dumptime(struct tm const *); static time_t hunt(timezone_t, time_t, time_t, bool); static void show(timezone_t, char *, time_t, bool); @@ -97,7 +97,7 @@ static void showextrema(timezone_t, char *, time_t, struct tm *, time_t); static void showtrans(char const *, struct tm const *, time_t, char const *, char const *); static const char *tformat(void); -static time_t yeartot(intmax_t) ATTRIBUTE_REPRODUCIBLE; +ATTRIBUTE_REPRODUCIBLE static time_t yeartot(intmax_t); /* Is C an ASCII digit? */ static bool @@ -125,7 +125,7 @@ is_alpha(char a) } } -static ATTRIBUTE_NORETURN void +ATTRIBUTE_NORETURN static void size_overflow(void) { fprintf(stderr, _("%s: size overflow\n"), progname); @@ -134,7 +134,7 @@ size_overflow(void) /* Return A + B, exiting if the result would overflow either ptrdiff_t or size_t. */ -static ATTRIBUTE_REPRODUCIBLE ptrdiff_t +ATTRIBUTE_REPRODUCIBLE static ptrdiff_t sumsize(size_t a, size_t b) { #ifdef ckd_add @@ -151,7 +151,7 @@ sumsize(size_t a, size_t b) /* Return a pointer to a newly allocated buffer of size SIZE, exiting on failure. SIZE should be nonzero. */ -static void * ATTRIBUTE_MALLOC +ATTRIBUTE_MALLOC static void * xmalloc(size_t size) { void *p = malloc(size); @@ -916,7 +916,7 @@ showextrema(timezone_t tz, char *zone, time_t lo, struct tm *lotmp, time_t hi) # include <stdarg.h> /* A substitute for snprintf that is good enough for zdump. */ -static int ATTRIBUTE_FORMAT((printf, 3, 4)) +ATTRIBUTE_FORMAT((printf, 3, 4)) static int my_snprintf(char *s, size_t size, char const *format, ...) { int n; diff --git a/zic.c b/zic.c index 892414af..f143fcef 100644 --- a/zic.c +++ b/zic.c @@ -459,20 +459,20 @@ static char roll[TZ_MAX_LEAPS]; ** Memory allocation. */ -static ATTRIBUTE_NORETURN void +ATTRIBUTE_NORETURN static void memory_exhausted(const char *msg) { fprintf(stderr, _("%s: Memory exhausted: %s\n"), progname, msg); exit(EXIT_FAILURE); } -static ATTRIBUTE_NORETURN void +ATTRIBUTE_NORETURN static void size_overflow(void) { memory_exhausted(_("size overflow")); } -static ATTRIBUTE_REPRODUCIBLE ptrdiff_t +ATTRIBUTE_REPRODUCIBLE static ptrdiff_t size_sum(size_t a, size_t b) { #ifdef ckd_add @@ -487,7 +487,7 @@ size_sum(size_t a, size_t b) size_overflow(); } -static ATTRIBUTE_REPRODUCIBLE ptrdiff_t +ATTRIBUTE_REPRODUCIBLE static ptrdiff_t size_product(ptrdiff_t nitems, ptrdiff_t itemsize) { #ifdef ckd_mul @@ -502,7 +502,7 @@ size_product(ptrdiff_t nitems, ptrdiff_t itemsize) size_overflow(); } -static ATTRIBUTE_REPRODUCIBLE ptrdiff_t +ATTRIBUTE_REPRODUCIBLE static ptrdiff_t align_to(ptrdiff_t size, ptrdiff_t alignment) { ptrdiff_t lo_bits = alignment - 1, sum = size_sum(size, lo_bits); @@ -526,7 +526,7 @@ memcheck(void *ptr) return ptr; } -static void * ATTRIBUTE_MALLOC +ATTRIBUTE_MALLOC static void * emalloc(size_t size) { return memcheck(malloc(size)); @@ -538,7 +538,7 @@ erealloc(void *ptr, size_t size) return memcheck(realloc(ptr, size)); } -static char * ATTRIBUTE_MALLOC +ATTRIBUTE_MALLOC static char * estrdup(char const *str) { return memcheck(strdup(str)); @@ -608,7 +608,7 @@ eat(int fnum, lineno num) eats(fnum, num, 0, -1); } -static void ATTRIBUTE_FORMAT((printf, 1, 0)) +ATTRIBUTE_FORMAT((printf, 1, 0)) static void verror(const char *const string, va_list args) { /* @@ -626,7 +626,7 @@ verror(const char *const string, va_list args) fprintf(stderr, "\n"); } -static void ATTRIBUTE_FORMAT((printf, 1, 2)) +ATTRIBUTE_FORMAT((printf, 1, 2)) static void error(const char *const string, ...) { va_list args; @@ -636,7 +636,7 @@ error(const char *const string, ...) errors = true; } -static void ATTRIBUTE_FORMAT((printf, 1, 2)) +ATTRIBUTE_FORMAT((printf, 1, 2)) static void warning(const char *const string, ...) { va_list args; @@ -666,7 +666,7 @@ close_file(FILE *stream, char const *dir, char const *name, } } -static ATTRIBUTE_NORETURN void +ATTRIBUTE_NORETURN static void usage(FILE *stream, int status) { fprintf(stream, @@ -3597,7 +3597,7 @@ lowerit(char a) } /* case-insensitive equality */ -static ATTRIBUTE_REPRODUCIBLE bool +ATTRIBUTE_REPRODUCIBLE static bool ciequal(register const char *ap, register const char *bp) { while (lowerit(*ap) == lowerit(*bp++)) @@ -3606,7 +3606,7 @@ ciequal(register const char *ap, register const char *bp) return false; } -static ATTRIBUTE_REPRODUCIBLE bool +ATTRIBUTE_REPRODUCIBLE static bool itsabbr(register const char *abbr, register const char *word) { if (lowerit(*abbr) != lowerit(*word)) @@ -3622,7 +3622,7 @@ itsabbr(register const char *abbr, register const char *word) /* Return true if ABBR is an initial prefix of WORD, ignoring ASCII case. */ -static ATTRIBUTE_REPRODUCIBLE bool +ATTRIBUTE_REPRODUCIBLE static bool ciprefix(char const *abbr, char const *word) { do @@ -3725,14 +3725,14 @@ getfields(char *cp, char **array, int arrayelts) return nsubs; } -static ATTRIBUTE_NORETURN void +ATTRIBUTE_NORETURN static void time_overflow(void) { error(_("time overflow")); exit(EXIT_FAILURE); } -static ATTRIBUTE_REPRODUCIBLE zic_t +ATTRIBUTE_REPRODUCIBLE static zic_t oadd(zic_t t1, zic_t t2) { #ifdef ckd_add @@ -3746,7 +3746,7 @@ oadd(zic_t t1, zic_t t2) time_overflow(); } -static ATTRIBUTE_REPRODUCIBLE zic_t +ATTRIBUTE_REPRODUCIBLE static zic_t tadd(zic_t t1, zic_t t2) { #ifdef ckd_add -- 2.37.2

2 1

[PROPOSED] Simplify zdump average-taking
by Paul Eggert Dec. 1, 2022

Dec. 1, 2022

* zdump.c (hunt): Simplify slightly, so that one more instruction can be int width rather than time_t width if that’s what the compiler prefers. No need to mention C89 in the comment, as C89 support is going away soon. (The code still happens to work in C89, for what it’s worth.) --- zdump.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/zdump.c b/zdump.c index a020102..04953dc 100644 --- a/zdump.c +++ b/zdump.c @@ -732,13 +732,9 @@ hunt(timezone_t tz, time_t lot, time_t hit, bool only_ok) for ( ; ; ) { /* T = average of LOT and HIT, rounding down. - Avoid overflow, even on oddball C89 platforms - where / rounds down and TIME_T_MIN == -TIME_T_MAX - so lot / 2 + hit / 2 might overflow. */ - time_t t = (lot / 2 - - ((lot % 2 + hit % 2) < 0) - + ((lot % 2 + hit % 2) == 2) - + hit / 2); + Avoid overflow. */ + int rem_sum = lot % 2 + hit % 2; + time_t t = (rem_sum == 2) - (rem_sum < 0) + lot / 2 + hit / 2; if (t == lot) break; tm_ok = my_localtime_rz(tz, &t, &tm) != NULL; -- 2.38.1

3 5

Re: [tz] New change in Mexico
by Brian Inglis Nov. 30, 2022

Nov. 30, 2022

On 2022-11-29 22:37, Tim Parenti wrote: > On Tue, 29 Nov 2022 at 13:29, Paul Eggert wrote: > I expect I didn't recognize > that as including Ciudad Juárez as opposed to one of the plain Juárezes > which also exist in Mexico. > On Tue, 29 Nov 2022 at 19:50, Heitor David Pinto wrote: > The municipalities have well-defined boundaries, see this map: > https://cuentame.inegi.org.mx/mapas/pdf/entidades/div_municipal/chihmpios.p… > Ah, that seems to be part of the issue — while the word "municipality" is often > used to refer to an individual settlement in US English, a "municipio" in Mexico > (and similar words in many other countries) is a second-level administrative > division, which is more akin to, say, a county in much of the US or a civil > parish in much of Britain. That is, these lists are not of individual > settlements which are far apart (although they often share names with such), but > rather of well-defined regions — administrative subdivisions of states — which, > as Heitor points out, cover the entire border. > https://en.wikipedia.org/wiki/Municipio <https://en.wikipedia.org/wiki/Municipio> > https://en.wikipedia.org/wiki/Municipalities_of_Mexico > <https://en.wikipedia.org/wiki/Municipalities_of_Mexico> > While "municipio" does, admittedly, seem to be best translated to English as > "municipality", since the English word has many meanings, it's maybe best to be > more faithful to the original Spanish use here for clarity. We've left > "municipio" untranslated in nearby commentary for Mexico before, so I've applied > the attached to the development repository to hopefully alleviate some further > confusion for others who might come to these comments unaware of some of the > details of Mexico's political subdivisions. While I don't necessarily expect > many more one-off adjustments to the new arrangement in the immediate future, if > that does come to pass, it might behoove us to further standardize our > commentary for the various Mexican zones (in a similar manner as was done for > the many Russian zones in 2014). > Anyway, that puts the dividing line between the two resultant zones along the > border between the municipio of Guadalupe to the northwest and the municipios of > Coyame del Sotol and Ojinaga to the southeast …which meets the US border between > Barrio Alto and Presidio de Pilares, about 15 km south-southeast of my > (comparatively uninformed) guess, which I suppose wasn't all too bad for a > ~900-km-long border. Same in most European countries and Canadian provinces: https://en.wikipedia.org/wiki/Local_government_in_Canada#Regional_municipal… "Depending on the province, this second tier may be called a county, regional municipality, regional district or regional county municipality." There are also some district, island, mountain resort, resort, rural, and specialized municipalities, each of which may have varying geographic extents as an administrative chunk of a province. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

1 0

[PROPOSED 1/4] Always define STD_INSPIRED
by Paul Eggert Nov. 30, 2022

Nov. 30, 2022

* private.h (STD_INSPIRED): Default to 0. All uses changed. This is purely refactoring, so that STD_INSPIRED is more like other macros in this file. --- Makefile | 2 +- localtime.c | 10 +++++----- private.h | 7 +++++-- theory.html | 2 +- 4 files changed, 12 insertions(+), 9 deletions(-) diff --git a/Makefile b/Makefile index 2c09f94..f0cbf7f 100644 --- a/Makefile +++ b/Makefile @@ -363,7 +363,7 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ # -DNETBSD_INSPIRED=0 # to the end of the "CFLAGS=" line. Otherwise, the functions # "localtime_rz", "mktime_z", "tzalloc", and "tzfree" are added to the -# time library, and if STD_INSPIRED is also defined the functions +# time library, and if STD_INSPIRED is also defined to nonzero the functions # "posix2time_z" and "time2posix_z" are added as well. # The functions ending in "_z" (or "_rz") are like their unsuffixed # (or suffixed-by-"_r") counterparts, except with an extra first diff --git a/localtime.c b/localtime.c index 1d22d35..462d054 100644 --- a/localtime.c +++ b/localtime.c @@ -1697,7 +1697,7 @@ gmtime(const time_t *timep) return gmtime_r(timep, &tm); } -#ifdef STD_INSPIRED +#if STD_INSPIRED struct tm * offtime(const time_t *timep, long offset) @@ -1706,7 +1706,7 @@ offtime(const time_t *timep, long offset) return gmtsub(gmtptr, timep, offset, &tm); } -#endif /* defined STD_INSPIRED */ +#endif /* ** Return the number of leap years through the end of the given year @@ -2325,7 +2325,7 @@ mktime(struct tm *tmp) return t; } -#ifdef STD_INSPIRED +#if STD_INSPIRED time_t timelocal(struct tm *tmp) { @@ -2377,7 +2377,7 @@ leapcorr(struct state const *sp, time_t t) ** XXX--is the below the right way to conditionalize?? */ -#ifdef STD_INSPIRED +#if STD_INSPIRED /* NETBSD_INSPIRED_EXTERN functions are exported to callers if NETBSD_INSPIRED is defined, and are private otherwise. */ @@ -2462,7 +2462,7 @@ posix2time(time_t t) return t; } -#endif /* defined STD_INSPIRED */ +#endif /* STD_INSPIRED */ #if TZ_TIME_T diff --git a/private.h b/private.h index 9cb9c24..b5fdf5a 100644 --- a/private.h +++ b/private.h @@ -691,7 +691,10 @@ extern long altzone; ** declarations if time_tz is defined. */ -#ifdef STD_INSPIRED +#ifndef STD_INSPIRED +# define STD_INSPIRED 0 +#endif +#if STD_INSPIRED # if TZ_TIME_T || !defined offtime struct tm *offtime(time_t const *, long); # endif @@ -738,7 +741,7 @@ struct tm *localtime_rz(timezone_t restrict, time_t const *restrict, time_t mktime_z(timezone_t restrict, struct tm *restrict); timezone_t tzalloc(char const *); void tzfree(timezone_t); -# ifdef STD_INSPIRED +# if STD_INSPIRED # if TZ_TIME_T || !defined posix2time_z time_t posix2time_z(timezone_t, time_t) ATTRIBUTE_REPRODUCIBLE; # endif diff --git a/theory.html b/theory.html index 75e347f..f2b798b 100644 --- a/theory.html +++ b/theory.html @@ -1173,7 +1173,7 @@ The vestigial <abbr>API</abbr>s are: </li> <li> The functions that are conditionally compiled - if <code>STD_INSPIRED</code> is defined should, at this point, be + if <code>STD_INSPIRED</code> is nonzero should, at this point, be looked on primarily as food for thought. They are not in any sense "standard compatible" – some are not, in fact, specified in <em>any</em> standard. -- 2.38.1

1 3

New change in Mexico
by Heitor David Pinto Nov. 30, 2022

Nov. 30, 2022

Hello, Mexico is planning to change time zones again. Last month, the whole state of Chihuahua moved to UTC-6 without DST, causing a time change across the border with the US for part of the year. Now the northern municipalities want to have the same time zone as the respective neighboring cities in the US, for example Juárez in UTC-7 with DST, matching El Paso, and Ojinaga in UTC-6 with DST, matching Presidio. The congress of Chihuahua and the federal Chamber and Senate all approved the change, following the combined procedure specified in the new time zone law, and now it awaits the president's approval. The change should occur on the day after the official publication of the law, again on short notice.https://politica.expansion.mx/congreso/2022/11/24/aprueban-que-ayuntamientos-fronterizos-de-chihuahua-tengan-horario-de-verano But there is another problem. The actual law that was passed says that Juárez and Ojinaga will observe UTC-7 and UTC-6 during the DST period, not outside of it. I think that this was an oversight as a result of trying to pass the law through all the chambers very quickly, but I can't believe that no one noticed it. There is a legislative procedure in Mexico called "fe de erratas" to correct obvious mistakes without having to pass the law again, but in this case the correction would have to alter multiple sections so I'm not sure if it will be possible. Either way, I expect confusion in the next days.http://gaceta.diputados.gob.mx/PDF/65/2022/nov/20221124-VII.pdf Regards,Dave

5 12

Re: [tz] [PROPOSED 2/5] Pacify gcc -std=c89 -pedantic with new attributes
by Brian Inglis Nov. 29, 2022

Nov. 29, 2022

On 2022-11-28 12:47, Paul Eggert via tz wrote: > On 2022-11-28 05:40, Philip Newton wrote: >> "have has" is a bit ugly.... > > Yes, I originally used the name "HAVE___HAS_C_ATTRIBUTE", since it tests whether > __has_c_attribute exists and that's the naming convention, but I changed it to > HAVE_HAS_C_ATTRIBUTE as I worried that the three adjacent underscores would be > confusing. If people prefer HAVE___HAS_C_ATTRIBUTE we can easily change to that. > The longer name would be more consistent. "4.2.8 __has_c_attribute The special operator __has_c_attribute (operand) may be used in ‘#if’ and ‘#elif’ expressions in C code to test whether the attribute referenced by its operand is recognized by GCC in attributes using the ‘[[]]’ syntax." How about HAVE_C23_ATTRIBUTE_CHECK, HAVE_C2X_ATTRIBUTE_CHECK, or something similarly more meaningful and less confusing? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

2 1

[tz-announce] 2022g release of tz code and data available
by Paul Eggert via tz-announce Nov. 29, 2022

Nov. 29, 2022

The 2022g release of the tz code and data is available. This release contains the following changes: Briefly: The northern edge of Chihuahua changes to US timekeeping. Much of Greenland stops changing clocks after March 2023. Fix some pre-1996 timestamps in northern Canada. C89 is now deprecated; please use C99 or later. Portability fixes for AIX, libintl, MS-Windows, musl, z/OS In C code, use more C23 features if available. C23 timegm now supported by default Fixes for unlikely integer overflows Changes to future timestamps In the Mexican state of Chihuahua, the border strip near the US will change to agree with nearby US locations on 2022-11-30. The strip's western part, represented by Ciudad Juárez, switches from -06 all year to -07/-06 with US DST rules, like El Paso, TX. The eastern part, represented by Ojinaga, will observe US DST next year, like Presidio, TX. (Thanks to Heitor David Pinto.) A new Zone America/Ciudad_Juarez splits from America/Ojinaga. Much of Greenland, represented by America/Nuuk, stops observing winter time after March 2023, so its daylight saving time becomes standard time. (Thanks to Jonas Nyrup and Jürgen Appel.) Changes to past timestamps Changes for pre-1996 northern Canada (thanks to Chris Walton): Merge America/Iqaluit and America/Pangnirtung into the former, with a backward compatibility link for the latter name. There is no good evidence the two locations differ since 1970. This change affects pre-1996 America/Pangnirtung timestamps. Cambridge Bay, Inuvik, Iqaluit, Rankin Inlet, Resolute and Yellowknife did not observe DST in 1965, and did observe DST from 1972 through 1979. Whitehorse moved from -09 to -08 on 1966-02-27, not 1967-05-28. Colombia's 1993 fallback was 02-06 24:00, not 04-04 00:00. (Thanks to Alois Treindl.) Singapore's 1981-12-31 change was at 16:00 UTC (23:30 local time), not 24:00 local time. (Thanks to Geoff Clare via Robert Elz.) Changes to code Although tzcode still works with C89, bugs found in recent routine maintenance indicate that bitrot has set in and that in practice C89 is no longer used to build tzcode. As it is a maintenance burden, support for C89 is planned to be removed soon. Instead, please use compilers compatible with C99, C11, C17, or C23. timegm, which tzcode implemented in 1989, will finally be standardized 34 years later as part of C23, so timegm is now supported even if STD_INSPIRED is not defined. Fix bug in zdump's tzalloc emulation on hosts that lack tm_zone. (Problem reported by Đoàn Trần Công Danh.) Fix bug in zic on hosts where malloc(0) yields NULL on success. (Problem reported by Tim McBrayer for AIX 6.1.) Fix zic configuration to avoid linkage failures on some platforms. (Problems reported by Gilmore Davidson and Igor Ivanov.) Work around MS-Windows nmake incompatibility with POSIX. (Problem reported by Manuela Friedrich.) Port mktime and strftime to debugging platforms where accessing uninitialized data has undefined behavior (strftime problem reported by Robert Elz). Check more carefully for unlikely integer overflows, preferring C23 <stdckdint.h> to overflow checking by hand, as the latter has had obscure bugs. Changes to build procedure New Makefile rule check_mild that skips checking whether Link lines are in the file 'backward'. (Inspired by a suggestion from Stephen Colebourne.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2022g.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2022g.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2022g.tar.lz The following convenience links are also available, although they may point to the previous release until the relevant caches are refreshed: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit 4e604e41115182c3ab1185bab4c888822511348e dated 2022-11-29 08:58:31 -0800 and tagged '2022g' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 5188edd8d05238a88da734cf78fadfb57640d4db3e7a0a9dddd70e3071e16b6eebc2e2ab17109b7dafafae68abfbc857df481cfdc3ffe63f7eb1569ea0b5997a tzcode2022g.tar.gz 7f79394295e00e3a24ebdbf9af3bc454a65f432a93b517e7e96c7f9db9949f6f5fdae9892a9d3789ff44ae0eb1bfe4744d36976b4624659af951d26414f94e65 tzdata2022g.tar.gz f471046189f519de5735ac2d8c3edb27cbe925247b06f44634e700e5e4453ec5f715d85256fc74d300bcdaa070a7600fcc054327f2dfe743ab3c0fe404ff83c1 tzdb-2022g.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmOGOvAACgkQ7ZfpDmKq fjSI4w/+PkVPCILI34+QeXIm6LLPhEPLxtb7q3rvfoBXk/qyottcPJvQXSAsqX/c Hus6lCNK0COyICVn48rf3ss+GNxLev/ZTMVLUBkH8WrgSe+5lPDjmaZjkbzIGPs8 L9TqE60K8DyeLNnZPf4Pkpx6o5r7uO3iQSN5qFyj5H82mDJ4vcQLZSNvDIA4+sRm +qmsBcn6Gk3EU3u3/YrxhuEY0ymUrJvm5LSG62CqLwA1Pd+REF70Ir5LdO4yJoUS blWe/CLUcnRfzMEK9/NGa1z3GtkisPYBCPnYJ93m2n4ASvFQ+R3t7NCEY2W+96ce 3kSPIX5W2g0/gcDTi1bxdLnQkO4RxtSQnlCjCae58dQNUgOa2X8mdRniRjjYC059 JY35VUzmX9wCPpcuq0iMbpOEWXeWga0ZDRmlZtZCwPKxkw+AhoJQVp5jxGNa4kwZ CZDjQga3ObvN8aQqMi9TpabJ4m2ZdN1yHQ7OTN80N67tHYMAbW0aY3J0JRIVjTHo P+8Y6FaCLzJA73BgnR7faiILXIPtXE54X+koo8x2Uwtrl8/wHsaPTippq96ts6Y6 3Zdr3EAQgAPhYtUgtHoIbLFBLjmyL5sUXOTwG/gMkUYXVkDpeBnc+BHrkv0Sjaw7 Vzz5HthhnSblP9bLB3KPTbbM0t+aypsSOYOSZWnIK8ANI9BdrNQ= =tSyt -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmOGOvAACgkQ7ZfpDmKq fjSedhAAu8XkzqB8NmXDYfEurBCUPe7zCBxBe7yqdt5W+tDA9snOtab3d8Oq7Lsb vNZfh4qHIxNbEYpoXOc0Qce3XKXGgyKDmZeFYQJ0ziqoZXetNLQEmg7T/H2m3GHl eo7K3w2hvyBB26FuDtimE5pzuJo9qJLXDp2SbOAbKa1w5HibyvZBOfcQozZ4CBmE mBc8LzyFY3zOhiy7CGYskqOzatNa0Eid95RkK2RXXTnN965N1qdyOz3z9SkJFH9h MR84VGYBmk0UGdPGmp1imkGmIrO/8AFny19ECCe4F74o2DFSPzANOaEh+i3fIP3d GNR96la9GGopmna+VNQt6zxdw4DHRoNkAupnJ2NVM0lbAMOG0mmwCFkCzW4gzTVm 7NdAtZyH+HjiKYPdQNIHbsvl0K1qIo1yXrb4jTd8eXaxA65msCOOwjqWk7a8ZjrJ NrLNmGeLow9svofEAeLpc9BUgwF90JGIlb+tPYovyj/xSU9vhQl1ZEmFYYdaN781 rGZ5jKtwBZWoAxW1Copf8S3jcxleSVMFo6MTEU+K+svZLd8SH5BnETa0fYWSTzKA uh2Y4V6pFe0/JVVC15mYkytbP6TC6prRmi44jRHtVRDtizGd7FFxYacIApkhBVi2 Qb8Qy+oZySwL+dbRlu+bA9nHIdACtxRouVEWpAecCBLaK3kBb7I= =6g+2 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmOGOvIACgkQ7ZfpDmKq fjT6/A/5AQdjRCEQngohVPQcxWE57FhHN+3Yq72iCbi64MhnL8sR+fHcni8CRb4f SIxi/tXeLdKJVV8+w7TBeQIDBDHrWXla2NSTHNcGREdp/wMoWagxBzAx3g2qQ7eT Qz6JhG4pHlOGK3u0/RESuCnhS/XmKTYj6BeDNc33LQ4iB0Lh+o9O/rz6jQyO3Y3L 84QMNJ4Edq/pOz9d9T1/cWO1j8Cn4Mled9WdCyOqZnhzRcJdbi/gDydC5aJIj1Fx 5OUrRwblIRVxMbK+kZA4D0lHR56KZb7NsaFGfsnW0m5zHUpXoGNYaFelKlWoRblO OEneM34IgNxsLhe9J9r/epSWB/14PmaY0zdXlNmKqELa7zYiJkiAwucPWtpxkPJG q6WPt4Pk4bWcud9esdgG7vjBz3ffrz2hUrmSMxuwLPHLuPRLrBoeMAmecFixGpea BUmR+XCPV9m19zcnvshBFGuLTNwFZSWBlUB9lWIocXc9cIMo4W/gNdUhnjb9L0+z VtAJzws1VcRV5zpkanwt+K50xjUlunxcRgLbLY2oMCpeDQyxH6DTnUr8RdJeMmvM ZPJYekxG0W8/eEjDOUFIQqvOtK1sQVhCZhjeciDW7to/K1p7DJy+g5g7lJn5KK4B Oz8vqmhdvdoIAK5uezPILpyJT7UpdUhmZ1WwQRqhk6G3jXPigQc= =Kyhr -----END PGP SIGNATURE-----

1 0

America/Nuuk changes from UTC-2 to UTC-2
by Jonas Nyrup Nov. 29, 2022

Nov. 29, 2022

On last Saturday in October 2023 when DST ends America/Nuuk will switch from -03/-02 to -02/-01 https://sermitsiaq.ag/forslagtidsforskel-danmark-mindskes-sommertid-beholdes describes the proposed bill about switching from UTC-3 to UTC-2 and that is not about abolishing DST as they do not want to make a decision on that matter before the rest of EU. https://sermitsiaq.ag/groenland-skifte-tidszone-trods-bekymringer writes that on November 24th 2022 the Parliament of Greenland approved the bill and that *the bill* will take effect on March 25th 2023 at 22:00 when DST begins. Both articles translates well with Google Translate. Inatsisartut = the Parliament of Greenland Naalakkersuisut = the government of Greenland I assume the official document will be published on https://naalakkersuisut.gl/kundgoerelser/2022?sc_lang=da Best regards Jonas Nyrup

2 2

[PROPOSED 0/5] Finish off support for C23 standard attributes
by Paul Eggert Nov. 28, 2022

Nov. 28, 2022

The attached patches update tzcode to use the remaining C23 standard attributes that look useful for tzcode. I don't see any tzcode use for the C23 attributes 'deprecated' and 'nodiscard'. Paul Eggert (5): Use C23 [[noreturn]] if available Pacify gcc -std=c89 -pedantic with new attributes Use C23 [[reproducible]] if available. Use C23 [[unsequenced]] if available Use C23 [[fallthrough]] if available Makefile | 2 +- date.c | 2 +- localtime.c | 4 +-- private.h | 77 ++++++++++++++++++++++++++++++++++++++++++++--------- zdump.c | 10 +++---- zic.c | 32 +++++++++++----------- 6 files changed, 90 insertions(+), 37 deletions(-) -- 2.37.2

2 7

Doubts about a typo fix
by Alejandro Colomar Nov. 26, 2022

Nov. 26, 2022

Hi Paul, I don't undertstand the commit shown below. It breaks the '-' symbol, which now is a hyphen. See the table mentioned yesterday: ┌──────────────────────────────────────────────────────────────────┐ │Keycap Appearance and meaning Special character and meaning │ ├──────────────────────────────────────────────────────────────────┤ │" " neutral double quote \[dq] neutral double quote │ │' ’ closing single quote \[aq] neutral apostrophe │ │- ‐ hyphen \- or \[-] minus sign/Unix dash │ │\ (escape character) \e or \[rs] reverse solidus │ │^ ˆ modifier circumflex \(ha circumflex/caret/“hat” │ │` ‘ opening single quote \(ga grave accent │ │~ ˜ modifier tilde \(ti tilde │ └──────────────────────────────────────────────────────────────────┘ So, at least, it should be (but I believe the initial code was correct): .q "zic \*\-r @$(date +%s)" However, I wonder what that \* is intending to do there (I can see no difference in my screen with or without it). Cheers, Alex --- commit 918e10e8963b3c0d38d3b5fb8ec9cf08ecd03757 Author: Paul Eggert <eggert(a)cs.ucla.edu> Date: Tue Jul 12 06:26:53 2022 -0700 * zic.8: fix minus typo diff --git a/zic.8 b/zic.8 index 0cd0781e..e8816e5b 100644 --- a/zic.8 +++ b/zic.8 @@ -145,7 +145,7 @@ .SH OPTIONS 31-bit signed integers. On platforms with GNU .BR date , -.q "zic \-r @$(date +%s)" +.q "zic \*-r @$(date +%s)" omits data intended for past timestamps. Although this option typically reduces the output file's size, the size can increase due to the need to represent the timestamp range -- <http://www.alejandro-colomar.es/>

5 7

New law about Time and Time zones in Greenland
by Jürgen Appel Nov. 25, 2022

Nov. 25, 2022

Dear all, i was made aware that on Thursday, 2022-11-24, a law proposal concerning time and time zones for Greenland was voted upon in Greenland Parliament: Reference (in Danish and Greenlandic): https://ina.gl/samlinger/oversigt-over-samlinger/samling/dagsordener/ dagsorden.aspx?lang=da&day=24-11-2022 https://ina.gl/media/2553527/pkt17_em2022_tidens_-bestemmelse_lov_da.pdf Translated with www.DeepL.com/Translator and annotated: =====[Proposal]===== Inatsisartut (Parliament of Greenland) Act on the Regulation of Time § 1. The standard time for Greenland shall be UTC -2. Clause 2. Naalakkersuisut (the Cabinet of Greenland) may establish rules that specified areas shall follow a different time zone than that determined in paragraph 1. Clause 3. Naalakkersuisut may establish rules on summer time. § 2. This Inatsisartut Act shall enter into force on 25 March 2023 at 22:00. Clause 2. At the same time, Landstingslov nr. 14 of 19 October 1989 regarding the application of summer time is repealed. Greenland Self-Government, x. xx xxx The President of Naalakkersuisut =================== If I understand this correctly, from the next planned switch to summer time, Greenland will permanently stay at that time, i.e. no switch back to winter time in 2023 will occur. Whether a switch to a shifted summer time will occur in spring 2024 is not completely transparent to me, as in some remarks (https://ina.gl/media/ 2554772/pkt17_em2022_tidens_bestemmelse_bet_2beh_da.pdf) it is written that no changes in the summer time regulations will be applied, and that this will occur only after EU has decided about the same topic. If some danish native speaker, or better yet someone from Greenland could confirm/clarify this, that would be nice. Also concerning "specified areas", i.e. today Ittoqqortoormiit (now UTC -1), Danmarkshavn (UTC +0), and Pituffik/Thule Air Base (UTC-4), I am unsure whether any changes are scheduled or whether the cabinet plans to keep/ reestablish the current rules. Best regards, Jürgen Appel -- Jürgen Appel Senior Scientist Denmark's National Metrology Institute Dansk Fundamental Metrologi, DFM A/S (dfm.dk) Kogle Allé 5 DK-2970 Hørsholm Denmark Mobile: +45 25459049 Email: jap(a)dfm.dk VAT: DK-29217939

2 1

Re: [tz] [PATCH v2 1/4] zic.8: Add public domain notice
by Brian Inglis Nov. 25, 2022

Nov. 25, 2022

On 2022-11-23 11:32, Paul Eggert via tz wrote: > The file already contains a public-domain notice at the bottom, in a > human-readable format that is visible to anybody who looks at the printable > version of the man page. No public domain notices appear in the *.?.txt source files or in the generated man pages. It may be useful to specify that the document, data, program, and source files for all components are in the public domain in the LICEN[CS]E sections. It would also be useful if you also added SPDX licence comments like man-pages after either your line(s) or theirs, such as: .\" SPDX-License-Identifier: LicenseRef-IANA-TZ-Public-Domain [suggested] .\" SPDX-FileCopyrightText: project authors [suggested] and also in the generated output?, as it may save downstreams doing so as licensing requirements are enforced by packaging tools and repos. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

2 1

[PROPOSED] Use C23 [[maybe_unused]] if available
by Paul Eggert Nov. 21, 2022

Nov. 21, 2022

* Makefile (GCC_DEBUG_FLAGS): Omit -Wno-unused-parameters, as the code is now safe for gcc -Wunused-parameters. * private.h (ATTRIBUTE_MAYBE_UNUSED): New macro. * localtime.c (gmtsub): * strftime.c (strftime_l) [HAVE_STRFTIME_L]: * zdump.c (gmtoff): Use it to mark possibly-unused parameters. * zdump.c (hunt): * zic.c (getleapdatetime): Omit unused arg. All callers changed. --- Makefile | 2 +- localtime.c | 4 ++-- private.h | 13 +++++++++++++ strftime.c | 2 +- zdump.c | 13 +++++++------ zic.c | 6 +++--- 6 files changed, 27 insertions(+), 13 deletions(-) diff --git a/Makefile b/Makefile index 92d78cb4..b2c6ff6f 100644 --- a/Makefile +++ b/Makefile @@ -300,7 +300,7 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ -Wtrampolines -Wundef -Wuninitialized -Wunused-macros -Wuse-after-free=3 \ -Wvariadic-macros -Wvla -Wwrite-strings \ -Wno-address -Wno-format-nonliteral -Wno-sign-compare \ - -Wno-type-limits -Wno-unused-parameter + -Wno-type-limits # # If your system has a "GMT offset" field in its "struct tm"s # (or if you decide to add such a field in your system's "time.h" file), diff --git a/localtime.c b/localtime.c index 7faa5d32..4dd9d259 100644 --- a/localtime.c +++ b/localtime.c @@ -1662,8 +1662,8 @@ localtime_r(const time_t *timep, struct tm *tmp) */ static struct tm * -gmtsub(struct state const *sp, time_t const *timep, int_fast32_t offset, - struct tm *tmp) +gmtsub(ATTRIBUTE_MAYBE_UNUSED struct state const *sp, time_t const *timep, + int_fast32_t offset, struct tm *tmp) { register struct tm * result; diff --git a/private.h b/private.h index 4d40582e..fee18cb2 100644 --- a/private.h +++ b/private.h @@ -433,6 +433,19 @@ typedef unsigned long uintmax_t; # define ATTRIBUTE_FORMAT(spec) /* empty */ #endif +#ifdef __has_c_attribute +# if __has_c_attribute(__maybe_unused__) +# define ATTRIBUTE_MAYBE_UNUSED [[__maybe_unused__]] +# endif +#endif +#ifndef ATTRIBUTE_MAYBE_UNUSED +# if 2 < __GNUC__ + (7 <= __GNUC_MINOR__) +# define ATTRIBUTE_MAYBE_UNUSED __attribute__ ((__unused__)) +# else +# define ATTRIBUTE_MAYBE_UNUSED /* empty */ +# endif +#endif + #if !defined _Noreturn && __STDC_VERSION__ < 201112 # if 2 < __GNUC__ + (8 <= __GNUC_MINOR__) # define _Noreturn __attribute__((__noreturn__)) diff --git a/strftime.c b/strftime.c index 9ea40fec..b23b6101 100644 --- a/strftime.c +++ b/strftime.c @@ -117,7 +117,7 @@ static char * _yconv(int, int, bool, bool, char *, char const *); #if HAVE_STRFTIME_L size_t strftime_l(char *s, size_t maxsize, char const *format, struct tm const *t, - locale_t locale) + ATTRIBUTE_MAYBE_UNUSED locale_t locale) { /* Just call strftime, as only the C locale is supported. */ return strftime(s, maxsize, format, t); diff --git a/zdump.c b/zdump.c index 89bcd25c..de1e1116 100644 --- a/zdump.c +++ b/zdump.c @@ -91,7 +91,7 @@ static bool errout; static char const *abbr(struct tm const *); static intmax_t delta(struct tm *, struct tm *) ATTRIBUTE_PURE; static void dumptime(struct tm const *); -static time_t hunt(timezone_t, char *, time_t, time_t, bool); +static time_t hunt(timezone_t, time_t, time_t, bool); static void show(timezone_t, char *, time_t, bool); static void showextrema(timezone_t, char *, time_t, struct tm *, time_t); static void showtrans(char const *, struct tm const *, time_t, char const *, @@ -627,7 +627,7 @@ main(int argc, char *argv[]) || (ab && (delta(&newtm, &tm) != newt - t || newtm.tm_isdst != tm.tm_isdst || strcmp(abbr(&newtm), ab) != 0))) { - newt = hunt(tz, argv[i], t, newt, false); + newt = hunt(tz, t, newt, false); newtmp = localtime_rz(tz, &newt, &newtm); newtm_ok = newtmp != NULL; if (iflag) @@ -707,7 +707,7 @@ yeartot(intmax_t y) return t; } -/* Search for a discontinuity in timezone TZ with name NAME, in the +/* Search for a discontinuity in timezone TZ, in the timestamps ranging from LOT through HIT. LOT and HIT disagree about some aspect of timezone. If ONLY_OK, search only for definedness changes, i.e., localtime succeeds on one side of the @@ -715,7 +715,7 @@ yeartot(intmax_t y) before the transition from LOT's settings. */ static time_t -hunt(timezone_t tz, char *name, time_t lot, time_t hit, bool only_ok) +hunt(timezone_t tz, time_t lot, time_t hit, bool only_ok) { static char * loab; static ptrdiff_t loabsize; @@ -807,7 +807,8 @@ adjusted_yday(struct tm const *a, struct tm const *b) my_gmtime_r and use its result instead of B. Otherwise, B is the possibly nonnull result of an earlier call to my_gmtime_r. */ static long -gmtoff(struct tm const *a, time_t *t, struct tm const *b) +gmtoff(struct tm const *a, ATTRIBUTE_MAYBE_UNUSED time_t *t, + ATTRIBUTE_MAYBE_UNUSED struct tm const *b) { #ifdef TM_GMTOFF return a->TM_GMTOFF; @@ -878,7 +879,7 @@ static void showextrema(timezone_t tz, char *zone, time_t lo, struct tm *lotmp, time_t hi) { struct tm localtm[2], gmtm[2]; - time_t t, boundary = hunt(tz, zone, lo, hi, true); + time_t t, boundary = hunt(tz, lo, hi, true); bool old = false; hi = (SECSPERDAY < hi - boundary ? boundary + SECSPERDAY diff --git a/zic.c b/zic.c index 8f8088ec..7a7a5094 100644 --- a/zic.c +++ b/zic.c @@ -1970,7 +1970,7 @@ inzsub(char **fields, int nfields, bool iscont) } static zic_t -getleapdatetime(char **fields, int nfields, bool expire_line) +getleapdatetime(char **fields, bool expire_line) { register const char * cp; register const struct lookup * lp; @@ -2048,7 +2048,7 @@ inleap(char **fields, int nfields) if (nfields != LEAP_FIELDS) error(_("wrong number of fields on Leap line")); else { - zic_t t = getleapdatetime(fields, nfields, false); + zic_t t = getleapdatetime(fields, false); if (0 <= t) { struct lookup const *lp = byword(fields[LP_ROLL], leap_types); if (!lp) @@ -2076,7 +2076,7 @@ inexpires(char **fields, int nfields) else if (0 <= leapexpires) error(_("multiple Expires lines")); else - leapexpires = getleapdatetime(fields, nfields, true); + leapexpires = getleapdatetime(fields, true); } static void -- 2.37.2

2 2

[PROPOSED] Prefer <stdckdint.h> for overflow checking
by Paul Eggert Nov. 20, 2022

Nov. 20, 2022

If <stdckdint.h> is available, or if its macros can be implemented easily, use the macros for overflow checking. This should help avoid future integer overflow bugs. * date.c (dogmt, timeout): * localtime.c (localsub, timesub, increment_overflow) (increment_overflow32, increment_overflow_time, time2sub): * zdump.c (sumsize, tzalloc): * zic.c (size_sum, size_product, grow_nitems_alloc, oadd, tadd): Prefer ckd_add etc. to doing overflow checking by hand. * private.h (HAVE_STDCKDINT_H): Default to true if __has_include(<stdckdint.h>). Include <stdckdint.h> if available. (ckd_add, ckd_sub, ckd_mul): Provide substitutes on recent-enough GCC-compatible compilers. --- Makefile | 2 ++ NEWS | 5 ++++- date.c | 10 ++++++++++ localtime.c | 33 +++++++++++++++++++++++++++++++++ private.h | 29 +++++++++++++++++++++++++++++ zdump.c | 12 ++++++++++++ zic.c | 31 +++++++++++++++++++++++++++++++ 7 files changed, 121 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 5ec0d4a..92d78cb 100644 --- a/Makefile +++ b/Makefile @@ -230,6 +230,8 @@ LDLIBS= # functions like 'link' or variables like 'tzname' required by POSIX # -DHAVE_SETENV=0 if your system lacks the setenv function # -DHAVE_SNPRINTF=0 if your system lacks the snprintf function +# -DHAVE_STDCKDINT_H=0 if neither <stdckdint.h> nor substitutes like +# __builtin_add_overflow work* # -DHAVE_STDINT_H=0 if <stdint.h> does not work* # -DHAVE_STRFTIME_L if <time.h> declares locale_t and strftime_l # -DHAVE_STRDUP=0 if your system lacks the strdup function diff --git a/NEWS b/NEWS index 7c46d3c..a401bee 100644 --- a/NEWS +++ b/NEWS @@ -4,6 +4,7 @@ News for the tz database Fix some pre-1996 timestamps in northern Canada. C89 is now deprecated; please use C99 or later. Portability fixes for AIX, libintl, MS-Windows, musl, z/OS + In C code, use more C23 features if available. C23 timegm now supported by default Fixes for unlikely integer overflows @@ -55,7 +56,9 @@ Unreleased, experimental changes uninitialized data has undefined behavior (strftime problem reported by Robert Elz). - Check more carefully for unlikely integer overflows. + Check more carefully for unlikely integer overflows, preferring + C23 <stdckdint.h> to overflow checking by hand, as the latter has + had obscure bugs. Changes to build procedure diff --git a/date.c b/date.c index cbc0ec1..1319462 100644 --- a/date.c +++ b/date.c @@ -122,8 +122,14 @@ dogmt(void) for (n = 0; environ[n] != NULL; ++n) continue; +#if defined ckd_add && defined ckd_mul + if (!ckd_add(&n, n, 2) && !ckd_mul(&n, n, sizeof *fakeenv) + && n <= SIZE_MAX) + fakeenv = malloc(n); +#else if (n <= min(PTRDIFF_MAX, SIZE_MAX) / sizeof *fakeenv - 2) fakeenv = malloc((n + 2) * sizeof *fakeenv); +#endif if (fakeenv == NULL) { fprintf(stderr, _("date: Memory exhausted\n")); errensure(); @@ -187,8 +193,12 @@ timeout(FILE *fp, char const *format, struct tm const *tmp) ptrdiff_t size = 1024 / 2; for ( ; ; ) { +#ifdef ckd_mul + bool bigger = !ckd_mul(&size, size, 2) && size <= SIZE_MAX; +#else bool bigger = (size <= min(PTRDIFF_MAX, SIZE_MAX) / 2 && (size *= 2, true)); +#endif char *newcp = bigger ? realloc(cp, size) : NULL; if (!newcp) { fprintf(stderr, diff --git a/localtime.c b/localtime.c index 7326567..7faa5d3 100644 --- a/localtime.c +++ b/localtime.c @@ -1565,6 +1565,14 @@ localsub(struct state const *sp, time_t const *timep, int_fast32_t setname, return NULL; /* "cannot happen" */ result = localsub(sp, &newt, setname, tmp); if (result) { +#if defined ckd_add && defined ckd_sub + if (t < sp->ats[0] + ? ckd_sub(&result->tm_year, + result->tm_year, years) + : ckd_add(&result->tm_year, + result->tm_year, years)) + return NULL; +#else register int_fast64_t newy; newy = result->tm_year; @@ -1574,6 +1582,7 @@ localsub(struct state const *sp, time_t const *timep, int_fast32_t setname, if (! (INT_MIN <= newy && newy <= INT_MAX)) return NULL; result->tm_year = newy; +#endif } return result; } @@ -1783,6 +1792,12 @@ timesub(const time_t *timep, int_fast32_t offset, y = newy; } +#ifdef ckd_add + if (ckd_add(&tmp->tm_year, y, -TM_YEAR_BASE)) { + errno = EOVERFLOW; + return NULL; + } +#else if (!TYPE_SIGNED(time_t) && y < TM_YEAR_BASE) { int signed_y = y; tmp->tm_year = signed_y - TM_YEAR_BASE; @@ -1793,6 +1808,7 @@ timesub(const time_t *timep, int_fast32_t offset, errno = EOVERFLOW; return NULL; } +#endif tmp->tm_yday = idays; /* ** The "extra" mods below avoid overflow problems. @@ -1867,6 +1883,9 @@ ctime_r(const time_t *timep, char *buf) static bool increment_overflow(int *ip, int j) { +#ifdef ckd_add + return ckd_add(ip, *ip, j); +#else register int const i = *ip; /* @@ -1879,22 +1898,30 @@ increment_overflow(int *ip, int j) return true; *ip += j; return false; +#endif } static bool increment_overflow32(int_fast32_t *const lp, int const m) { +#ifdef ckd_add + return ckd_add(lp, *lp, m); +#else register int_fast32_t const l = *lp; if ((l >= 0) ? (m > INT_FAST32_MAX - l) : (m < INT_FAST32_MIN - l)) return true; *lp += m; return false; +#endif } static bool increment_overflow_time(time_t *tp, int_fast32_t j) { +#ifdef ckd_add + return ckd_add(tp, *tp, j); +#else /* ** This is like ** 'if (! (TIME_T_MIN <= *tp + j && *tp + j <= TIME_T_MAX)) ...', @@ -1906,6 +1933,7 @@ increment_overflow_time(time_t *tp, int_fast32_t j) return true; *tp += j; return false; +#endif } static bool @@ -2029,11 +2057,16 @@ time2sub(struct tm *const tmp, return WRONG; } } +#ifdef ckd_add + if (ckd_add(&yourtm.tm_year, y, -TM_YEAR_BASE)) + return WRONG; +#else if (increment_overflow32(&y, -TM_YEAR_BASE)) return WRONG; if (! (INT_MIN <= y && y <= INT_MAX)) return WRONG; yourtm.tm_year = y; +#endif if (yourtm.tm_sec >= 0 && yourtm.tm_sec < SECSPERMIN) saved_seconds = 0; else if (yourtm.tm_year < EPOCH_YEAR - TM_YEAR_BASE) { diff --git a/private.h b/private.h index 4315a85..4d40582 100644 --- a/private.h +++ b/private.h @@ -392,6 +392,35 @@ typedef unsigned long uintmax_t; # define SIZE_MAX ((size_t) -1) #endif +/* Support ckd_add, ckd_sub, ckd_mul on C23 or recent-enough GCC-like + hosts, unless compiled with -DHAVE_STDCKDINT_H=0 or with pre-C23 EDG. */ +#if !defined HAVE_STDCKDINT_H && defined __has_include +# if __has_include(<stdckdint.h>) +# define HAVE_STDCKDINT_H true +# endif +#endif +#ifdef HAVE_STDCKDINT_H +# if HAVE_STDCKDINT_H +# include <stdckdint.h> +# endif +#elif defined __EDG__ +/* Do nothing, to work around EDG bug <https://bugs.gnu.org/53256>. */ +#elif defined __has_builtin +# if __has_builtin(__builtin_add_overflow) +# define ckd_add(r, a, b) __builtin_add_overflow(a, b, r) +# endif +# if __has_builtin(__builtin_sub_overflow) +# define ckd_sub(r, a, b) __builtin_sub_overflow(a, b, r) +# endif +# if __has_builtin(__builtin_mul_overflow) +# define ckd_mul(r, a, b) __builtin_mul_overflow(a, b, r) +# endif +#elif 7 <= __GNUC__ +# define ckd_add(r, a, b) __builtin_add_overflow(a, b, r) +# define ckd_sub(r, a, b) __builtin_sub_overflow(a, b, r) +# define ckd_mul(r, a, b) __builtin_mul_overflow(a, b, r) +#endif + #if 3 <= __GNUC__ # define ATTRIBUTE_CONST __attribute__((const)) # define ATTRIBUTE_MALLOC __attribute__((__malloc__)) diff --git a/zdump.c b/zdump.c index 669d8fd..89bcd25 100644 --- a/zdump.c +++ b/zdump.c @@ -137,9 +137,15 @@ size_overflow(void) static ATTRIBUTE_PURE ptrdiff_t sumsize(size_t a, size_t b) { +#ifdef ckd_add + ptrdiff_t sum; + if (!ckd_add(&sum, a, b) && sum <= SIZE_MAX) + return sum; +#else ptrdiff_t sum_max = min(PTRDIFF_MAX, SIZE_MAX); if (a <= sum_max && b <= sum_max - a) return a + b; +#endif size_overflow(); } @@ -254,9 +260,15 @@ tzalloc(char const *val) ptrdiff_t initial_nenvptrs = 1; /* Counting the trailing NULL pointer. */ while (*e++) { +# ifdef ckd_add + if (ckd_add(&initial_nenvptrs, initial_envptrs, 1) + || SIZE_MAX < initial_envptrs) + size_overflow(); +# else if (initial_nenvptrs == min(PTRDIFF_MAX, SIZE_MAX) / sizeof *environ) size_overflow(); initial_nenvptrs++; +# endif } fakeenv0size = sumsize(valsize, valsize); fakeenv0size = max(fakeenv0size, 64); diff --git a/zic.c b/zic.c index a69d4e0..8f8088e 100644 --- a/zic.c +++ b/zic.c @@ -475,18 +475,30 @@ size_overflow(void) static ATTRIBUTE_PURE ptrdiff_t size_sum(size_t a, size_t b) { +#ifdef ckd_add + ptrdiff_t sum; + if (!ckd_add(&sum, a, b) && sum <= SIZE_MAX) + return sum; +#else ptrdiff_t sum_max = min(PTRDIFF_MAX, SIZE_MAX); if (a <= sum_max && b <= sum_max - a) return a + b; +#endif size_overflow(); } static ATTRIBUTE_PURE ptrdiff_t size_product(ptrdiff_t nitems, ptrdiff_t itemsize) { +#ifdef ckd_mul + ptrdiff_t product; + if (!ckd_mul(&product, nitems, itemsize) && product <= SIZE_MAX) + return product; +#else ptrdiff_t nitems_max = min(PTRDIFF_MAX, SIZE_MAX) / itemsize; if (nitems <= nitems_max) return nitems * itemsize; +#endif size_overflow(); } @@ -536,11 +548,18 @@ static ptrdiff_t grow_nitems_alloc(ptrdiff_t *nitems_alloc, ptrdiff_t itemsize) { ptrdiff_t addend = (*nitems_alloc >> 1) + 1; +#if defined ckd_add && defined ckd_mul + ptrdiff_t product; + if (!ckd_add(nitems_alloc, *nitems_alloc, addend) + && !ckd_mul(&product, *nitems_alloc, itemsize) && product <= SIZE_MAX) + return product; +#else ptrdiff_t amax = min(PTRDIFF_MAX, SIZE_MAX); if (*nitems_alloc <= ((amax - 1) / 3 * 2) / itemsize) { *nitems_alloc += addend; return *nitems_alloc * itemsize; } +#endif memory_exhausted(_("integer overflow")); } @@ -3716,16 +3735,28 @@ time_overflow(void) static ATTRIBUTE_PURE zic_t oadd(zic_t t1, zic_t t2) { +#ifdef ckd_add + zic_t sum; + if (!ckd_add(&sum, t1, t2)) + return sum; +#else if (t1 < 0 ? ZIC_MIN - t1 <= t2 : t2 <= ZIC_MAX - t1) return t1 + t2; +#endif time_overflow(); } static ATTRIBUTE_PURE zic_t tadd(zic_t t1, zic_t t2) { +#ifdef ckd_add + zic_t sum; + if (!ckd_add(&sum, t1, t2) && min_time <= sum && sum <= max_time) + return sum; +#else if (t1 < 0 ? min_time - t1 <= t2 : t2 <= max_time - t1) return t1 + t2; +#endif if (t1 == min_time || t1 == max_time) return t1; time_overflow(); -- 2.38.1

1 0

[PROPOSED 0/6] unlikely integer overflow fixes
by Paul Eggert Nov. 20, 2022

Nov. 20, 2022

This patch set fixes some unlikely integer overflow bugs. These patches are relevant only for unusual situations, e.g., objects so large that their sizes exceed PTRDIFF_MAX bytes; or for unusual architectures, e.g., architectures where INT_MAX == UINT_MAX. In most cases I do not know of any practical way to exploit the bug, even if POSIX says the bug is possible. Paul Eggert (6): Don’t assume INT_MAX < UINT_FAST64_MAX Fix size_t overflow check if SIZE_MAX == INT_MAX date: integer overflow fixes Improve integer overflow checking in zdump Fix theoretical integer overflow in zic.c Fix another theoretical zic.c overflow NEWS | 3 ++ date.c | 32 +++++++------------ private.h | 4 +++ zdump.c | 64 +++++++++++++++++++++----------------- zic.c | 92 +++++++++++++++++++++++++++++++++++-------------------- 5 files changed, 113 insertions(+), 82 deletions(-) -- 2.38.1

1 6

[PATCH 1/5] Simplify inputline return value
by Paul Eggert Nov. 20, 2022

Nov. 20, 2022

* zic.c (inputline): Return bool, not ptrdiff_t. All callers changed. --- zic.c | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/zic.c b/zic.c index 548c1c5..0671889 100644 --- a/zic.c +++ b/zic.c @@ -1575,10 +1575,9 @@ associate(void) /* Read a text line from FP into BUF, which is of size BUFSIZE. Terminate it with a NUL byte instead of a newline. - Return the line's length, not counting the NUL byte. - On EOF, return a negative number. + Return true if successful, false if EOF. On error, report the error and exit. */ -static ptrdiff_t +static bool inputline(FILE *fp, char *buf, ptrdiff_t bufsize) { ptrdiff_t linelen = 0, ch; @@ -1589,7 +1588,7 @@ inputline(FILE *fp, char *buf, ptrdiff_t bufsize) exit(EXIT_FAILURE); } if (linelen == 0) - return -1; + return false; error(_("unterminated line")); exit(EXIT_FAILURE); } @@ -1604,7 +1603,7 @@ inputline(FILE *fp, char *buf, ptrdiff_t bufsize) } } buf[linelen] = '\0'; - return linelen; + return true; } static void @@ -1626,13 +1625,11 @@ infile(int fnum, char const *name) } wantcont = false; for (num = 1; ; ++num) { - ptrdiff_t linelen; char buf[_POSIX2_LINE_MAX]; int nfields; char *fields[MAX_FIELDS]; eat(fnum, num); - linelen = inputline(fp, buf, sizeof buf); - if (linelen < 0) + if (!inputline(fp, buf, sizeof buf)) break; nfields = getfields(buf, fields, sizeof fields / sizeof *fields); -- 2.38.1

1 4

[PROPOSED 0/4] Port to C89, and deprecate C89
by Paul Eggert Nov. 19, 2022

Nov. 19, 2022

While looking into fixing some bugs in tzcode, I noticed some places where existing code wouldn’t work with ancient C89 compilers. I fixed the problems I found in this patch series. Quite possibly other problems remain, problems that I didn’t notice. As nobody has reported C89-related problems for ages, it appears that these old compilers are no longer being used to compile tzcode. So I propose that we remove C89 support, to avoid future maintenance burdens such as the one I recently went through. As part of the transition away from C89 support, the last patch in this series announces that C89 will be removed in some future release. We can keep C89 support for at least one release longer. Paul Eggert (4): Port to C89 gcc -pedantic Port UINT_FAST64_MAX back to C89 Port int_fast64_t to C89 64-bit long * NEWS: Deprecate C89. NEWS | 7 +++++++ private.h | 47 +++++++++++++++++++++++------------------------ 2 files changed, 30 insertions(+), 24 deletions(-) -- 2.38.1

1 4

Re: [tz] Country name change from Turkey to Turkiye
by Brian Inglis Nov. 19, 2022

Nov. 19, 2022

On 2022-11-17 23:09, Bin Li via tz wrote: > Do you have any plans to change Turkey's name? Because it's the official name now. > https://www.npr.org/2022/06/03/1102841197/turkey-changes-its-official-name-… <https://www.npr.org/2022/06/03/1102841197/turkey-changes-its-official-name-…> One of the stupider ISO decisions, as English supports no accents, except in loanwords, and they are just ignored, except possibly in academic publishing. I think it is time native English language speakers push back against and ignore decisions made by international committees of non-native English language speakers, to try and change what native English language speakers use to what the foreign language uses in Latin alphabet transliterations, just as the other 100+ countries who have no "official" transliteration do. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

3 2

Country name change from Turkey to Turkiye
by Bin Li Nov. 18, 2022

Nov. 18, 2022

Dear, Do you have any plans to change Turkey's name? Because it's the official name now. https://www.npr.org/2022/06/03/1102841197/turkey-changes-its-official-name-…

6 8

New York Times: Time is Running Out for the Leap Second
by Jonathan Leffler Nov. 15, 2022

Nov. 15, 2022

https://www.nytimes.com/2022/11/14/science/time-leap-second.html -- Jonathan Leffler <jonathan.leffler(a)gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."

1 0

United States Senate reintroduced Sunshine Protection Act, enabling Permanent DST
by Phake Nick Nov. 14, 2022

Nov. 14, 2022

I don't quite understand the legal text of the bill itself [2], but according to my reading, it seems like the bill will end DST across the entire US by shifting the standard time forward an hour, except in states/territories/area that currently doesn't enact DST, which they can choose to follow the new standard time or old standard time? 1: https://www.rubio.senate.gov/public/index.cfm/2021/3/rubio-colleagues-reint… 2: https://www.rubio.senate.gov/public/_cache/files/d34c77c0-acea-4074-bc57-14…

18 26

[PATCH] use official source for 1993 end of time shift
by Alois Treindl Nov. 12, 2022

Nov. 12, 2022

--- southamerica | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/southamerica b/southamerica index 13cc65e..8eb5e25 100644 --- a/southamerica +++ b/southamerica @@ -1417,10 +1417,13 @@ Zone Antarctica/Palmer 0 - -00 1965 # Milne gives 4:56:16.4 for Bogotá time in 1899. He writes, # "A variation of fifteen minutes in the public clocks of Bogota is not rare." +# Alois Treindl quoted DECRETO 267 DE 1993 +# https://www.suin-juriscol.gov.co/viewDocument.asp?ruta=Decretos/1061335 +# Artículo 2° El cambio de hora se hará efectivo a las veinticuatro horas del día 6 de febrero del presente año. # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule CO 1992 only - May 3 0:00 1:00 - -Rule CO 1993 only - Apr 4 0:00 0 - +Rule CO 1993 only - Feb 7 0:00 0 - # Zone NAME STDOFF RULES FORMAT [UNTIL] #STDOFF -4:56:16.4 Zone America/Bogota -4:56:16 - LMT 1884 Mar 13 -- 1.8.3.1

2 1

Re: [tz] Minor (unimportant really) technical UB bug in strftime() ?
by Brian Inglis Nov. 12, 2022

Nov. 12, 2022

On 2022-11-11 13:53, Paul Eggert via tz wrote: > On 2022-11-10 16:11, Tom Lane wrote: > >> simple modifications of the >> strftime() case can provide pretty good examples. > I'm not sure I'm following this argument, but if I understand it correctly I > disagree. I very much much want implementations to reject attempts to use > uninitialized data, and I don't want the C standard to prohibit such > implementations. Use of uninitialized data is a serious problem in real > applications - several CVEs have arisen from it - and the C standard shouldn't > require implementations to sweep it under the rug. > This call is obviously buggy since it is passing an uninitialized struct tm to > strftime. However, the C standard says the patched strftime's memcpy initializes > strftime's local variable tm, and therefore mktime's use of tm's contents is > defined and the implementation allow the program's use of uninitialized data. > > Whatever the reason for this peculiarity of the C standard (and nobody seems to > remember why it's there), it's counterproductive. In general C programs > shouldn't use uninitialized data. If they do, it's useful to have a debugging > implementation that reports any such use the instant that it happens as this > will help catch real bugs. And since common debugging implementations like > valgrind and UBSan are not following the C standard here, this suggests that the > C standard is mistaken, not the implementations. >> That leads either to strftime() knowing >> much more about mktime()'s innards than it ought to > It's not a problem for strftime, since strftime's has to know what's needed in > the struct tm; this follows from strftime's API. It may not know everything about the object, as there may be implementatiion extensions to deal with e.g. localization issues, and can never know everything about another function implementation, which could be changed at any time. > It might be a problem for other scenarios, such as the one you vaguely suggested > though I don't know the details. However, even assuming these other scenarios > exist, they don't justify this peculiarity of the C standard. The standard > should not say that the ordinary meaning of "don't use uninitialized variables" > is wrong and that there's some trickier interpretation that hardly any > programmer knows and that was wrong even in C17 and so needed rewording (and > perhaps still needs rewording) and that nevertheless must be supported - even > though important debugging implementations disagree. I think the principle is just to program carefully and generically around possible issues, when dealing with an opaque object you do not define and control, to avoid creating issues with private fields or functions which may be part of the implementation, but not in whatever documented interface you are programming to. Not all the world is...C, POSIX, or Linux, compliant. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

1 0

Minor (unimportant really) technical UB bug in strftime() ?
by Robert Elz Nov. 11, 2022

Nov. 11, 2022

The code for the %s strftime conversion starts as: (this taken from tzcode2022f strftime.c - but I suspect that many versions are the same) case 's': { struct tm tm; char buf[INT_STRLEN_MAXIMUM( time_t) + 1]; time_t mkt; tm = *t; mkt = mktime(&tm); The "tm = *t;" line is the problem. It (or more correctly, something to replace that) is needed, as *t is const, strftime() is not permitted to modify it, yet the struct tm * passed to mktime() is not const, as mktime is sometimes required to modify that struct before returning. However, mktime() refers only to the fields tm_year tm_mon tm_mday tm_hour tm_min tm_sec and tm_isdst of the struct passed to it. The %s conversion is defined as producing (in a decimal string format) the result of mktime() applied to the struct tm passed to strftime. Hence an application which intends to use strftime(..., "%s", ...) need only initialise those 7 fields, the other 2 (currently) standard fields (tm_yday and tm_wday) are explicitly ignored by mktime() on input, so there is no need to assign those values, and any other fields that might exist in a particular implementation are out of scope for a portable (conforming) application to touch, so cannot be initialised. Since referring to an uninitialised variable is, I believe, technically undefined behaviour, doing a struct copy (copying all fields) can have that effect. (An application could memset() the entire struct before providing the values it must add, but is not required to do that). It seems likely that the simple fix is to replace the struct assignment with 7 individual assignment statements tm.tm_year = t->tm_year; tm.tm_mon = t->tm_mon; /* ... */ On the other hand, hardware that balks at simply loading or copying, uninitialised values, without using them for any purpose is not exactly common (and half the world's code would probably break if an implementation that worked in such a manner was ever created) so I'd call this one of the less significant issues to worry about fixing. kre

10 26

End of time change in Colombia 1993
by Alois Treindl Nov. 10, 2022

Nov. 10, 2022

TZ has for Colombia a single period with time zone 4h west. # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule CO 1992 only - May 3 0:00 1:00 - Rule CO 1993 only - Apr 4 0:00 0 - I think the end date 4 April is wrong, it should be 6 February 24h or 7 February 0h The time shift was called Hora Gaviria, and caused by shortage of electricity in connection with El Niño . Source: *DECRETO 267 DE 1993 * https://www.suin-juriscol.gov.co/viewDocument.asp?ruta=Decretos/1061335 *Artículo 1° *Adoptar como hora legal en el territorio de la República, la del Tiempo Universal Coordinado, UTC, disminuido en cinco (5) horas. *Artículo 2° *El cambio de hora se hará efectivo a las veinticuatro horas del día 6 de febrero del presente año. There is also a newspaper article https://www.eltiempo.com/archivo/documento/MAM-32922 of 4 feb 1993, but the text is less clear to my limited understanding of Spanish. See also https://es.wikipedia.org/wiki/Crisis_energ%C3%A9tica_de_1992_en_Colombia **

1 1

[PROPOSED] Support timegm by default, as per C23
by Paul Eggert Nov. 10, 2022

Nov. 10, 2022

Also, fix a bug in timegm; it sometimes modified its input even on failure. * Makefile, NEWS: Mention this. * localtime.c (mktmcpy): New static function. (time2sub): Use it. (timegm, timeoff): Define even if !STD_INSPIRED. (timeoff): Make it static if !STD_INSPIRED. (timegm): Do not modify *TMP on failure, even if only to change TMP->is_isdst. * private.h (HAVE_DECL_TIMEGM): Specify reasonable default value. (timegm): Always declare one way or another. --- Makefile | 8 +++----- NEWS | 5 +++++ localtime.c | 53 +++++++++++++++++++++++++++++++++-------------------- private.h | 18 +++++++++++++++--- 4 files changed, 56 insertions(+), 28 deletions(-) diff --git a/Makefile b/Makefile index 9ee15607..5ec0d4ab 100644 --- a/Makefile +++ b/Makefile @@ -209,6 +209,7 @@ LDLIBS= # For example, N is 252460800 on AmigaOS. # -DHAVE_DECL_ASCTIME_R=0 if <time.h> does not declare asctime_r # -DHAVE_DECL_ENVIRON if <unistd.h> declares 'environ' +# -DHAVE_DECL_TIMEGM=0 if <time.h> does not declare timegm # -DHAVE_DIRECT_H if mkdir needs <direct.h> (MS-Windows) # -DHAVE_GENERIC=0 if _Generic does not work* # -DHAVE_GETRANDOM if getrandom works (e.g., GNU/Linux), @@ -344,14 +345,11 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ # If you want functions that were inspired by early versions of X3J11's work, # add # -DSTD_INSPIRED -# to the end of the "CFLAGS=" line. This arranges for the functions -# "offtime", "timelocal", "timegm", "timeoff", -# "posix2time", and "time2posix" to be added to the time conversion library. +# to the end of the "CFLAGS=" line. This arranges for the following +# functions to be added to the time conversion library. # "offtime" is like "gmtime" except that it accepts a second (long) argument # that gives an offset to add to the time_t when converting it. # "timelocal" is equivalent to "mktime". -# "timegm" is like "timelocal" except that it turns a struct tm into -# a time_t using UT (rather than local time as "timelocal" does). # "timeoff" is like "timegm" except that it accepts a second (long) argument # that gives an offset to use when converting to a time_t. # "posix2time" and "time2posix" are described in an included manual page. diff --git a/NEWS b/NEWS index 4a053077..23f1f7f1 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,7 @@ News for the tz database Briefly: Fix some pre-1996 timestamps in northern Canada + C23 timegm now supported by default Unreleased, experimental changes @@ -22,6 +23,10 @@ Unreleased, experimental changes Changes to code + timegm, which tzcode implemented in 1989, will finally be + standardized 34 years later as part of C23, so timegm is now + supported even if STD_INSPIRED is not defined. + Fix bug in zdump's tzalloc emulation on hosts that lack tm_zone. (Problem reported by Đoàn Trần Công Danh.) diff --git a/localtime.c b/localtime.c index 712be135..9935b5d3 100644 --- a/localtime.c +++ b/localtime.c @@ -1951,6 +1951,23 @@ tmcomp(register const struct tm *const atmp, return result; } +/* Copy to *DEST from *SRC. Copy only the members needed for mktime, + as other members might not be initialized. */ +static void +mktmcpy(struct tm *dest, struct tm *const src) +{ + dest->tm_sec = src->tm_sec; + dest->tm_min = src->tm_min; + dest->tm_hour = src->tm_hour; + dest->tm_mday = src->tm_mday; + dest->tm_mon = src->tm_mon; + dest->tm_year = src->tm_year; + dest->tm_isdst = src->tm_isdst; +#if defined TM_GMTOFF && ! UNINIT_TRAP + dest->TM_GMTOFF = src->TM_GMTOFF; +#endif +} + static time_t time2sub(struct tm *const tmp, struct tm *(*funcp)(struct state const *, time_t const *, @@ -1972,17 +1989,7 @@ time2sub(struct tm *const tmp, struct tm yourtm, mytm; *okayp = false; - - yourtm.tm_sec = tmp->tm_sec; - yourtm.tm_min = tmp->tm_min; - yourtm.tm_hour = tmp->tm_hour; - yourtm.tm_mday = tmp->tm_mday; - yourtm.tm_mon = tmp->tm_mon; - yourtm.tm_year = tmp->tm_year; - yourtm.tm_isdst = tmp->tm_isdst; -#if defined TM_GMTOFF && ! UNINIT_TRAP - yourtm.TM_GMTOFF = tmp->TM_GMTOFF; -#endif + mktmcpy(&yourtm, tmp); if (do_norm_secs) { if (normalize_overflow(&yourtm.tm_min, &yourtm.tm_sec, @@ -2289,7 +2296,6 @@ mktime(struct tm *tmp) } #ifdef STD_INSPIRED - time_t timelocal(struct tm *tmp) { @@ -2297,13 +2303,9 @@ timelocal(struct tm *tmp) tmp->tm_isdst = -1; /* in case it wasn't initialized */ return mktime(tmp); } - -time_t -timegm(struct tm *tmp) -{ - return timeoff(tmp, 0); -} - +#else +static +#endif time_t timeoff(struct tm *tmp, long offset) { @@ -2313,7 +2315,18 @@ timeoff(struct tm *tmp, long offset) return time1(tmp, gmtsub, gmtptr, offset); } -#endif /* defined STD_INSPIRED */ +time_t +timegm(struct tm *tmp) +{ + time_t t; + struct tm tmcpy; + mktmcpy(&tmcpy, tmp); + tmcpy.tm_wday = -1; + t = timeoff(&tmcpy, 0); + if (0 <= tmcpy.tm_wday) + *tmp = tmcpy; + return t; +} static int_fast32_t leapcorr(struct state const *sp, time_t t) diff --git a/private.h b/private.h index 7cbd56d2..7320173f 100644 --- a/private.h +++ b/private.h @@ -543,9 +543,24 @@ struct tm *localtime(time_t const *); struct tm *localtime_r(time_t const *restrict, struct tm *restrict); time_t mktime(struct tm *); time_t time(time_t *); +time_t timegm(struct tm *); void tzset(void); #endif +#ifndef HAVE_DECL_TIMEGM +# if (202311 <= __STDC_VERSION__ \ + || defined __GLIBC__ || defined __tm_zone /* musl */ \ + || defined __FreeBSD__ || defined __NetBSD__ || defined __OpenBSD__ \ + || (defined __APPLE__ && defined __MACH__)) +# define HAVE_DECL_TIMEGM true +# else +# define HAVE_DECL_TIMEGM false +# endif +#endif +#if !HAVE_DECL_TIMEGM && !defined timegm +time_t timegm(struct tm *); +#endif + #if !HAVE_DECL_ASCTIME_R && !defined asctime_r extern char *asctime_r(struct tm const *restrict, char *restrict); #endif @@ -582,9 +597,6 @@ extern long altzone; # if TZ_TIME_T || !defined offtime struct tm *offtime(time_t const *, long); # endif -# if TZ_TIME_T || !defined timegm -time_t timegm(struct tm *); -# endif # if TZ_TIME_T || !defined timelocal time_t timelocal(struct tm *); # endif -- 2.37.2

1 0

No Daylight Savings in Fiji For year 2022-2023
by Jashneel Kumar Nov. 9, 2022

Nov. 9, 2022

Dear Timezone Support, I would like to inform you that there will be no Daylight Saving in Fiji this year. Can you please check that the same is reflected in the time zone database. Regards, [New_VF_Icon_RGB_RED] Jashneel Kumar Manager Data Networks & Services Jashneel.Kumar(a)vodafone.com.fj<mailto:Jashneel.Kumar@vodafone.com.fj> Vodafone Fiji PTE Limited, 168 Princes Rd, Tamavua, Suva, Fiji Islands www.vodafone.com.fj<http://www.vodafone.com.fj/> Together we can [Vodafone] ________________________________ The content of this email including any attachments is confidential and may contain information that is proprietary and privileged. If you are not the intended recipient be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify E-mail Administrator on info(a)vodafone.com.fj Please also destroy and delete this message from your system. Vodafone Fiji PTE Limited does not guarantee that this message is free from computer virus or any other defect. The reader accepts full responsibility for taking defensive and counteractive action needed to rectify the computer virus or other defects caused. Vodafone Fiji PTE Limited : Private Mail Bag, Suva, Fiji | Telephone : +679 3312000 | E-Mail : info(a)vodafone.com.fj Please consider your environmental responsibility before printing this e-mail [https://www.vodafone.com.fj//images/default-source/logo/logo-2x.png] Vodafone Fiji PTE Ltd <https://www.vodafone.com.fj/>

3 5

Yukon, NWT, and Nunavut (Canada)
by Chris Walton Nov. 7, 2022

Nov. 7, 2022

There are some inaccuracies in the TZ database rules for Northern Canada between the years 1965 and 1995. ---------------------------------------------------------------------------------------- *Item A: On Sunday April 25, 1965, all parts of the Yukon switched to Yukon Double Daylight Time (YDDT). * This event is recorded in the database, but the associated rules have been incorrectly extended to cover almost all of Northern Canada. News article 1: *Whitehorse Star *—* Thursday April 22, 1965 *—* page 1* title: *DST Starts Monday* > > Yukon Daylight Saving Time starts this weekend. Clocks will be turned > ahead two hours after midnight Saturday, April 24 and there may be a lot of > people late for church this Sunday. > Trial period for DST was approved by Territorial Council last month for > this summer, after which a second look may be taken from Yukoners' point of > view. Two hour change was adopted to fall in line with British Columbia > and Alberta summer times. https://www.newspapers.com/image/578587481/ The title of this first article is wrong and/or misleading. Also, the start time shown in the article is vague; it simply says "after midnight" when it probably should have stated 2:00a.m. News article 2: *Whitehorse Star *—* Thursday April 29, 1965 *—* page 1* title: *DST Continues 'Till Hallowe'en* > Daylight Saving Time started in the Yukon five days ago, and already the > Commissioner's office is being besieged with calls from sleepy local > citizens wanting to know when it's going to end. > The two-hour change which began Sunday at two a.m. brings the Territory > into line with B.C. and Alberta time for the summer, but three hours ahead > for travelers from Alaska. > An official said Wednesday that many calls have come in from people asking > how long the experiment will last. The answer is another six months. > Date for the change back to Yukon Standard Time Oct. 31 at two a.m. https://www.newspapers.com/image/578588221/ News article 3: *Whitehorse Star *—* Monday October 25, 1965 *—* page 15* > Commissioner G.C. Cameron announced today that daylight Saving Time will > come to an end, for this year, at 2a.m. October 31. This means that all > clocks and watches should be turned back two hours as of that date. > The double daylight saving time was adopted this summer, on a trial basis > , so that Yukon time would correspondent with British Columbia and Alberta > time. > ... https://www.newspapers.com/image/578589147/ The 1965 Yukon Council minutes can be found here: http://assets.yukonarchives.ca/PER_YG_06_1965_C20_S02_v1.pdf Unfortunately I could not find an official CO or OIC. It is clear from the council minutes and the newspaper articles that the Yukon government wanted the clocks to be in sync with British Columbia and Alberta for the summer. However, the Yukon council members never once mentioned NWT (Northwest Territories) when debating or discussing the time change. I do not currently believe that NWT touched any of its clocks in 1965. Keep in mind that the land currently under the jurisdiction of Nunavut belonged to NWT prior to 1999. *All of the 1965 clock transitions for NWT and Nunavut should be removed from the TZ database unless somebody can provide compelling evidence to support them.* Zones in need of fixing: America/Yellowknife (NWT) America/Inuvik (NWT) America/Iqaluit (Nunavut) America/Cambridge_Bay (Nunavut) America/Pangnirtung (Nunavut) America/Rankin_Inlet (Nunavut) America/Resolute (Nunavut) *For the two Yukon zones, the April 25, 1965 start time should probably be changed in the TZ database from 00:00 to 2:00am.* Zones in need of fixing: America/Whitehorse America/Dawson ---------------------------------------------------------------------------------------- *Item B: On Sunday February 27, 1966, the part of the Yukon that lies east of the 136th meridian and south of the 62nd parallel switched from UTC-9 to UTC-8.* This change was mandated by Commissioner's Order 1966-20. Brian Inglis referenced it in a 2015 posting to this mailing list. https://mm.icann.org/pipermail/tz/2015-April/022200.html Brian was unable to locate a copy of the Commissioner's Order or any details about it. He simply stated "no online source found". I found two newspaper articles which give us the missing details: News article 1: *Whitehorse Star *—* Thursday Feb 24,1966 *—* page 2* title: *It's Time for YDT* > Sometime between midnight Saturday, Feb. 26 and Sunday morning Feb. 27, > residents of the southern part of the Yukon will get a bonus of an extra > hour for Rendezvous celebrating. > That's the date for changeover to Yukon Daylight Time which resulted from > the recent territorial plebiscite on the subject. > From Whitehorse to Watson Lake, settlements will observe the fast time; > elsewhere, Yukoners will remain on Yukon Standard Time. > Whitehorse, Ross River, Carcross, Teslin, Brooks Brook, Johnson's > Crossing, Watson Lake and Upper Liard... when the clock is wound at > midnight this Saturday, the hands should be set ahead one hour... to one > o'clock Yukon Daylight Time. https://www.newspapers.com/image/578575979/ I don't think that the author understood that moving the clock forward meant an hour was lost instead of gained! Oh well! Also, it was a permanent change and should not have been considered to be "daylight time". News article 2 (with more detail): *Whitehorse Star *—* Thursday March 3, 1966 *—* page 15* title: *Standard Time for Election* > Returning Officer R. B. COUSINS Wednesday received a reply from Chief > Electoral Officer N. Castonguay, in Ottawa, ruling on the matter of time > changes in Yukon affecting the territorial by-election in Whitehorse West > next Monday. His Message read as follows: > "Commissioner's Order 1966-20, dated January 27, 1966, provides from and > after midnight February 26, Yukon Standard Time as defined by section 36 of > the Interpretation Ordinance shall be reckoned in the same manner as > Pacific Standard Time. That is eight hours behind Greenwich Mean Time for > the area lying east of 136 degrees longitude and west and south of 62 > degrees latitude. In the remainder of the territory Yukon standard time > shall be reckoned as nine hours behind Greenwich mean time. This means > that in Whitehorse, Yukon Standard Time is eight hours behind Greenwich > Mean Time and all operations of Canada Elections Act in your electoral > district are governed by Yukon Standard Time. Advise all candidates and > other parties interested." > In other words, Yukon time in Whitehorse Monday for purposes of voting > will be the same as anything else... Yukon Southern Standard. https://www.newspapers.com/image/578577076/ There is a typo in this article where it says "and west and south". It presumably should have stated "lying east of 136° West longitude and south of 62° North latitude". *This change is not currently reflected in the TZ database; it should be applied to America/Whitehorse as a permanent change from UTC-9(YST) to UTC-8(PST) at 00:00 on Sunday February 27, 1966.* Zones in need of fixing: America/Whitehorse ---------------------------------------------------------------------------------------- *Item C: On Sunday May 28, 1967, the Yukon redefined the boundary between UTC-9 and UTC-8 to be a single straight line running along the 138th Meridian.* This change was a result of Commissioner's Order 1967-59 which can be seen at https://articles.adsabs.harvard.edu//full/1970JRASC..64..129T/0000156.000.h… page 156. Brian Inglis already quoted the Commissioner's Order on this mailing list (in the same posting I mentioned for item B above), but I will provide it again here. > COMMISSIONER'S ORDER 1967-59: > 1. Commissioner's Order 1966-20 dated at Whitehorse in the Yukon > Territory on 27th January, 1966, is hereby revoked. > 2. Yukon (East) Standard Time as defined by section 36 of the > Interpretation Ordinance from and after mid-night on the 28th day of May, > 1967 shall be reckoned in the same manner as Pacific Standard Time, that is > to say, eight hours behind Greenwich Time in the area of the Yukon > Territory lying east of the 138th degree longitude west. > 3. In the remainder of the Territory, lying west of the 138th degree > longitude west, Yukon (West) Standard Time shall be reckoned as nine hours > behind Greenwich Time. News article: *Whitehorse Star *—* Thursday May 11, 1967 *—* page 1* title: *Don't Touch That Clock* > The Yukon will be going on a new double time system after midnight May 28 > but Whitehorse residents won't notice the change. > Neither will most of the residents in other Yukon communities. > The change will place everyone on the east side of the 138 meridian on > Pacific Standard Time which is the same as Yukon Southern Standard Time > which is the same as Yukon Eastern Standard Time which is what most of > these people are on now. > Everyone on the west side of the 138th meridian will be on Yukon Standard > Time, or nine hours behind Greenwich time, which is Yukon Northern Standard > Time which is Yukon Western Standard Time, which is what they're on now. > The meridian runs north and south through the territory, passing near > Gravel Lake on the Stewart-Dawson Road, and just past Haines Junction on > the Alaska Highway. > This means that residents of Haines Junction, who petitioned for the > change several months ago, will now be on the same time as Whitehorse, > moving their clocks ahead one hour at midnight May 28. The same applies to > Carmacks residents, and some in Mayo and Keno. > Elsa adopted Whitehorse time for practical business reasons some time ago. > Announcing the forthcoming change to Territorial Council this week, > Commissioner J. Smith said the new system will be tried for a year and if > it doesn't work out, the entire territory will revert to one time zone > again. https://www.newspapers.com/image/578592950/ The Commissioner's Order and the newspaper article both refer to "midnight" on May 28. This possibly should be interpreted as "00:00 Sunday May 28" instead of "24:00 Sunday May 28" because a scheduled change for a Sunday night seems unlikely. However, the exact time and date is moot for the purposes of the TZ database because the change did not affect either Dawson City or Whitehorse. If it were not for the 1970 cutoff policy in the TZ database, we would need a new zone named "America/Carmacks" or "America/Haines_Junction"... and only then would we need to worry about the exact date and time of the transition. It seems like we might also have needed "America/Elsa". *The TZ database currently shows America/Whitehorse changing from UTC-9 to UTC-8 at 00:00 May 28, 1967; this rule is incorrect because Whitehorse had already transitioned to UTC-8 the year before. See item (B) above.* Zones in need of fixing: America/Whitehorse ---------------------------------------------------------------------------------------- *Item D: The Northwest Territories has been using daylight saving every summer since 1972.* News article 1: *Whitehorse Star *—* Friday April 28,1972 *—* page 6* title: *Daylight Saving Time for N.W.T.* > The Northwest Territories goes on daylight saving time at 2 a.m. on Sunday > when residents will set their clocks ahead one hour. > The only exception is the community of Coral Harbour on Southampton Island > which will remain unchanged in order that residents there will be on the > same time as those in the Keewatin. > Coral Harbour is in the eastern time zone and is one hour ahead of the > Keewatin region which operates in the central time zone. > Daylight saving time in the Territories is necessary to eliminate the > confusion in work hours between northern and southern Canada. > The move is being made because Alberta will be going on daylight saving > time for the first time on a province-wide basis at the same time. > If the NWT did not follow suit, all Alberta communities would be one hour > ahead of communities in the Mackenzie District of the NWT causing > difficulties and confusion in respect to transportation scheduling and > radio programming https://www.newspapers.com/image/578701610/ <https://www.newspapers.com/image/578701610/> The implication is that NWT started using daylight saving at 2:00a.m. on Sunday April 30,1972 which matches the records we have for Alberta. Note: there is a blog about this at https://cabinradio.ca/91751/news/remembering-the-start-of-daylight-saving-i… The blog has an image of the same newspaper article; it claims the article was published on April 18 instead of April 28 but that is an error. Another bit of proof that NWT (and much of Canada) was already using daylight saving prior to 1980 lies in the wording of the following Yukon article: *Whitehorse Star *—* Friday April 25,1980 *—* page 1* title: *Turn Your Clock Ahead Sunday* > As of 2 a.m next Sunday, Yukoners will become the last people across > Canada to join the ranks of the enlightened — on daylight saving time. > Clocks will be turned ahead one hour. That means on Sunday morning, what > was 7:00 last week will then be 8:00. Standard time resumes next October. > So you'll get one less hour's sleep tomorrow night. Daylight saving is > said to save on energy and even reduce crime. But don't lose any sleep over > it. https://www.newspapers.com/image/578597701/ Obviously I would have preferred to cite a Yellowknife (NWT) newspaper instead of a Whitehorse (Yukon) newspaper, but I could not find online archives of Yellowknife newspapers for the applicable time frame. *Nunavut and NWT zones should be updated in the TZ database to show observance of DST starting in 1972 instead of 1980.Start and End dates should be the same as the rest of Canada (last Sunday in April to last Sunday in October) with all transitions at 2:00a.m.* Zones in need of fixing: America/Yellowknife (NWT) America/Inuvik (NWT) America/Iqaluit (Nunavut) America/Cambridge_Bay (Nunavut) America/Pangnirtung (Nunavut) America/Rankin_Inlet (Nunavut) America/Resolute (Nunavut) Note that no changes are required for the two Yukon zones that correctly show Yukon reinstating daylight saving in 1980. ---------------------------------------------------------------------------------------- *Item E: Pangnirtung* A comment in the TZ database northamerica file reads: "Pangnirtung switched to eastern time; we'll guess 1995." Context: The communities of Pangnirtung and Qikiqtarjuaq (Broughton Island) are located on the east side of Baffin Island in Nunavut; they sit east of 68°W and according to the old NWT legislation, they were both supposed to have been on Atlantic Time. The 5th edition of the Atlas of Canada contains a time zone map that shows both legislated and observed time zone boundaries. All communities on Baffin Island are shown to be *observing *Eastern time. The date on the map is 1984. https://ftp.maps.canada.ca/pub/nrcan_rncan/raster/atlas_5_ed/eng/other/ referencemaps/mcr4056.pdf The implication is that Pangnirtung and Qikiqtarjuaq have observed Eastern Time as far back as 1984 (and likely even further back than that). It is possible that these communities never actually observed Atlantic Time, but that would be difficult to prove. *The TZ database rules for America/Pangirtung should be adjusted to show Eastern Time as far back as at least 1984.* Theoretically the zone could also be moved to the backzone file due to lack of any reliable history between 1970 and 1984; but I am not going to actively push for that. Zones in need of fixing: America/Pangnirtung (Nunavut) FYI: There is an older time zone map in the 4th edition of the Atlas of Canada. It has a date of 1967. Unfortunately it shows only the legislated boundaries which are not useful to us. https://ftp.maps.canada.ca/pub/nrcan_rncan/raster/atlas_4_ed/eng/economic/ transportationandcommunications/225_226.pdf ---------------------------------------------------------------------------------------- -chris

2 2

Bug in 2022f version of zic.c
by Tim McBrayer Nov. 7, 2022

Nov. 7, 2022

Hi, tzcode2022f/zic.c has a bug in its memory checker routine in static void* memcheck(void*). This code throws an error and exits when the pointer returned by malloc is NULL. However, malloc is allowed to return a NULL pointer when the allocation size is 0. And, on one machine I am building the TZ code on, malloc(0) does indeed return NULL. This is an AIX 6.1 box, with C compiler xlC 13.01.0000.0011. This is easy enough to work around locally. However, it would be nice to get this fixed for any future release of the TZ code. --- Tim McBrayer Ab Initio Software NOTICE from Ab Initio: This email (including any attachments) may contain information that is subject to confidentiality obligations or is legally privileged, and sender does not waive confidentiality or privilege. If received in error, please notify the sender, delete this email, and make no further use, disclosure, or distribution.

4 4

[PROPOSED] Generate nicer 'make check' output
by Paul Eggert Nov. 6, 2022

Nov. 6, 2022

* Makefile (DIFF_TZS): New macro. (check_tzs, $(TIME_T_ALTERNATIVES)): Use it. --- Makefile | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 8c4c6aba..9ee15607 100644 --- a/Makefile +++ b/Makefile @@ -499,6 +499,11 @@ TARFLAGS= `if tar $(GNUTARFLAGS) --version >/dev/null 2>&1; \ # Flags to give 'gzip' when making a distribution. GZIPFLAGS= -9n +# When comparing .tzs files, use GNU diff's -F'^TZ=' option if supported. +# This makes it easier to see which Zone has been affected. +DIFF_TZS= diff -u$$(! diff -u -F'^TZ=' - - <>/dev/null >&0 2>&1 \ + || echo ' -F^TZ=') + ############################################################################### #MAKE= make @@ -857,7 +862,7 @@ check_tables: checktab.awk $(YDATA) backward $(ZONETABLES) check_tzs: $(TZS) $(TZS_NEW) if test -s $(TZS); then \ - diff -u $(TZS) $(TZS_NEW); \ + $(DIFF_TZS) $(TZS) $(TZS_NEW); \ else \ cp $(TZS_NEW) $(TZS); \ fi @@ -1058,7 +1063,7 @@ $(TIME_T_ALTERNATIVES): $(VERSION_DEPS) TZS_YEAR="$$range" TZS_CUTOFF_FLAG="-t $$range" \ D=$$wd/$@.dir \ to$$range.tzs) && \ - diff -u $(TIME_T_ALTERNATIVES_HEAD).dir/to$$range.tzs \ + $(DIFF_TZS) $(TIME_T_ALTERNATIVES_HEAD).dir/to$$range.tzs \ $@.dir/to$$range.tzs && \ if diff -q Makefile Makefile 2>/dev/null; then \ quiet_option='-q'; \ -- 2.37.2

1 0

[PROPOSED] Fix unlikely conversion bug in zic
by Paul Eggert Nov. 5, 2022

Nov. 5, 2022

* zic.c (puttzcode): Arg is zic_t, not int_fast32_t. This fixes a portability bug on platforms where int_fast32_t is a 32-bit ones’ complement or signed-magnitude integer, and where the argument is -2**31 before conversion to int_fast32_t. Although I don’t know of any such platforms, the C standard allows them. --- zic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zic.c b/zic.c index d8bdbb96..548c1c5f 100644 --- a/zic.c +++ b/zic.c @@ -2216,7 +2216,7 @@ convert64(uint_fast64_t val, char *buf) } static void -puttzcode(const int_fast32_t val, FILE *const fp) +puttzcode(zic_t val, FILE *fp) { char buf[4]; -- 2.37.2

2 1

Mexico on track to abolish DST
by Paul Eggert Nov. 3, 2022

Nov. 3, 2022

Yesterday Mexico's Chamber of Deputies voted 445–33 to abolish DST in most of Mexico, and although there are more hurdles I expect this to become law. When that happens, I hope the following simple patch will suffice; it merely changes "max" to "2022" in the last two Mexico Rule lines. We'll also need to add commentary citing the law, etc., but you can try this patch now if you like, to debug any applications involving future time in Mexico. Today timeanddate updated their English-language summary of this <https://www.timeanddate.com/news/time/mexico-remove-dst-2022.html>. I haven't installed the following. diff --git a/northamerica b/northamerica index da84f354..2466d627 100644 --- a/northamerica +++ b/northamerica @@ -2634,2 +2634,2 @@ Rule Mexico 2001 only - Sep lastSun 2:00 0 S -Rule Mexico 2002 max - Apr Sun>=1 2:00 1:00 D -Rule Mexico 2002 max - Oct lastSun 2:00 0 S +Rule Mexico 2002 2022 - Apr Sun>=1 2:00 1:00 D +Rule Mexico 2002 2022 - Oct lastSun 2:00 0 S

4 16

Re: [tz] iana build failures on Windows
by Paul Eggert Nov. 2, 2022

Nov. 2, 2022

On 4/19/21 7:09 AM, Manuela Friedrich wrote: > I had to include signal.h in zic.c to prevent the following error: > > zic.c(610): error C2061: syntax error: identifier 'got_signal' This is a portability bug recently introduced to zic.c. I installed the first attached patch to fix it. > The I needed to resolved error > > zic.obj : error LNK2019: unresolved external symbol tz_time referenced in function random_dirent This appears to be another recent portability bug. It's related to a portability problem you reported on MS-Windows in response to which in 2018d I committed a patch that introduced RESERVE_STD_EXT_IDS: https://github.com/eggert/tz/commit/24b45243c5210b4196987fdd06e6c288c358a268 When I recently added the randomish filename code to the development version, I neglected to deal with RESERVE_STD_EXT_IDS. The second attached patch should fix this issue. Please give the two patches a try, as I don't use MS-Windows and can't easily test these patches on that platform. > a test run of zdump -v produced way more output than in the last release, the Linux output seems to have become longer too, but maybe this is still under development. That change is intentional, and was caused by this: https://github.com/eggert/tz/commit/ac07b446a3afaa4cb1ae11a91785a201c91f6351 along with some neighboring commits. Thanks for reporting the problems, and I hope the current development version of tzdb addresses the issues you mentioned.

5 23

Errors compiling 2022f on macOS
by Gilmore Davidson Nov. 1, 2022

Nov. 1, 2022

Hi, I’m getting errors when running make on the 2022f release, on my macOS Monterrey (12.6.1) machine. There are two separate errors. When I run `make` with no arguments, I get the following: cc -DTZDIR='"/usr/share/zoneinfo"' -c -o zic.o zic.c zic.c:1194:11: error: implicit declaration of function 'getrandom' is invalid in C99 [-Werror,-Wimplicit-function-declaration] s = getrandom(entropy_buffer, sizeof entropy_buffer, 0); ^ 1 error generated. After some digging, I tried running `make CFLAGS="-DHAVE_GETRANDOM=0”`, which then presents a different error: cc -DTZDIR='"/usr/share/zoneinfo"' -o zic -DHAVE_GETRANDOM=0 zic.o Undefined symbols for architecture x86_64: "_libintl_gettext", referenced from: _main in zic.o _close_file in zic.o _usage in zic.o _warning in zic.o _infile in zic.o _adjleap in zic.o _associate in zic.o ... "_libintl_setlocale", referenced from: _main in zic.o "_libintl_textdomain", referenced from: _main in zic.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) I’m not a C programmer so I’m out of my depth with trying to diagnose workarounds. Possibly there’s just another CFLAGS argument I need to provide, or I’ve got something else weird in my environment? Some extra bits of context: These errors also happen on latest `main` branch (commit 9f1f40cd). I can compile 2022e without issue. The getrandom error appears in commit 0733c65c ("Improve randomness of zic temp file names”). The linking error appears in commit e5b2ee63 ("Use C23 __has_include if available”). masOS 12.6.1 / Make 3.81 / clang 14.0.0 Also, the Makefile comment for the HAVE_GETRANDOM flag says "-DHAVE_GETRANDOM if getgrandom works (e.g., GNU/Linux)*” — is “getgrandom” a typo? Cheers, Gil

4 13

zic.c - compilation broken on gcc 4.8.3 after commit e5b2ee634c7151484c06740ea2c8a4d4a75409b6
by Иванов Игорь Oct. 31, 2022

Oct. 31, 2022

Good time of day. This commit breaks compilation at least on GCC 4.8.3: commit e5b2ee634c7151484c06740ea2c8a4d4a75409b6 Author: Paul Eggert <eggert(a)cs.ucla.edu> Date: Thu Oct 20 11:41:27 2022 -0700 Use C23 __has_include if available It causes this compilation error: zic.c: In function ‘main’: zic.c:813:16: error: ‘optarg’ undeclared (first use in this function) if (strcmp(optarg, "slim") == 0) { ^ zic.c:906:6: error: ‘optind’ undeclared (first use in this function) if (optind == argc - 1 && strcmp(argv[optind], "=") == 0) ^ Specifically hunks like this are problematic: @@ -55,8 +63,8 @@ #endif #ifndef HAVE_GETTEXT -# define HAVE_GETTEXT 0 -#endif /* !defined HAVE_GETTEXT */ +# define HAVE_GETTEXT HAS_INCLUDE(<libintl.h>, false) +#endif #ifndef HAVE_INCOMPATIBLE_CTIME_R # define HAVE_INCOMPATIBLE_CTIME_R 0 The culprit is the replacement 0 -> false and 1 -> true. Apparently it breaks #if preprocessor logic in older compilers somewhere downstream - what was #if 1 becomes #if true, which GCC treats as "false" and falls into #else branch. "Restoring" false and true back to 0 and 1 seems to fix the issue. Best regards, Igor Ivanov, Software engineer at DSSL

2 3

Syria Time has changed
by Rami M Oct. 31, 2022

Oct. 31, 2022

2 1

Grouped country lists are confusing
by Stephen Colebourne Oct. 31, 2022

Oct. 31, 2022

Recent changes merged the comments acting as country headers. Thus, a typical merged header is now: # Denmark # Germany # Norway # Sweden It is very confusing to suggest that all four countries are evenly represented here, as the commentary is typically all about the primary country (Germany in this case). The alphabetical list is decidedly unhelpful too, as nothing indicates which country the Zone's city relates to. Can I propose these comments be altered to something like: # Germany # also applicable since 1970 to Denmark # also applicable since 1970 to Norway # also applicable since 1970 to Sweden thanks Stephen

4 6

[tz-announce] 2022f release of tz code and data available
by Paul Eggert via tz-announce Oct. 30, 2022

Oct. 30, 2022

The 2022f release of the tz code and data is available. This release contains the following changes. The most urgent one is the change for Chihuahua, Mexico which affects timestamps starting Sunday. Briefly: Mexico will no longer observe DST except near the US border. Chihuahua moves to year-round -06 on 2022-10-30. Fiji no longer observes DST. Move links to 'backward'. In vanguard form, GMT is now a Zone and Etc/GMT a link. zic now supports links to links, and vanguard form uses this. Simplify four Ontario zones. Fix a Y2438 bug when reading TZif data. Enable 64-bit time_t on 32-bit glibc platforms. Omit large-file support when no longer needed. In C code, use some C23 features if available. Remove no-longer-needed workaround for Qt bug 53071. Changes to future timestamps Mexico will no longer observe DST after 2022, except for areas near the US border that continue to observe US DST rules. On 2022-10-30 at 02:00 the Mexican state of Chihuahua moves from -07 (-06 with DST) to year-round -06, thus not changing its clocks that day. The new law states that Chihuahua near the US border no longer observes US DST. (Thanks to gera for the heads-up about Chihuahua.) Fiji will not observe DST in 2022/3. (Thanks to Shalvin Narayan.) For now, assume DST is suspended indefinitely. Changes to data Move links to 'backward' to ease and simplify link maintenance. This affects generated data only if you use 'make BACKWARD='. GMT is now a Zone and Etc/GMT a link instead of vice versa, as GMT is needed for leap second support whereas Etc/GMT is not. However, this change exposes a bug in TZUpdater 2.3.2 so it is present only in vanguard form for now. Vanguard form now uses links to links, as zic now supports this. Changes to past timestamps Simplify four Ontario zones, as most of the post-1970 differences seem to have been imaginary. (Problem reported by Chris Walton.) Move America/Nipigon, America/Rainy_River, and America/Thunder_Bay to 'backzone'; backward-compatibility links still work, albeit with some different timestamps before November 2005. Changes to code zic now supports links to links regardless of input line order. For example, if Australia/Sydney is a Zone, the lines Link Australia/Canberra Australia/ACT Link Australia/Sydney Australia/Canberra now work correctly, even though the shell commands ln Australia/Canberra Australia/ACT ln Australia/Sydney Australia/Canberra would fail because the first command attempts to use a link Australia/Canberra that does not exist until after the second command is executed. Previously, zic had unspecified behavior if a Link line's target was another link, and zic often misbehaved if a Link line's target was a later Link line. Fix line number in zic's diagnostic for a link to a link. Fix a bug that caused localtime to mishandle timestamps starting in the year 2438 when reading data generated by 'zic -b fat' when distant-future DST transitions occur at times given in standard time or in UT, not the usual case of local time. This occurs when the corresponding .zi Rule lines specify DST transitions with TO columns of 'max' and AT columns that end in 's' or 'u'. The number 2438 comes from the 32-bit limit in the year 2038, plus the 400-year Gregorian cycle. (Problem reported by Bradley White.) On glibc 2.34 and later, which optionally supports 64-bit time_t on platforms like x86 where time_t was traditionally 32 bits, default time_t to 64 instead of 32 bits. This lets functions like localtime support timestamps after the year 2038, and fixes year-2038 problems in zic when accessing files dated after 2038. To continue to limit time_t to 32 bits on these platforms, use "make CFLAGS='-D_TIME_BITS=32'". In C code, do not enable large-file support on platforms like AIX and macOS that no longer need it now that tzcode does not use off_t or related functions like 'stat'. Large-file support is still enabled by default on GNU/Linux, as it is needed for 64-bit time_t support. In C code, prefer C23 keywords to pre-C23 macros for alignof, bool, false, and true. Also, use the following C23 features if available: __has_include, unreachable. zic no longer works around Qt bug 53071, as the relevant Qt releases have been out of support since 2019. This change affects only fat TZif files, as thin files never had the workaround. zdump no longer modifies the environ vector when compiled on platforms lacking tm_zone or when compiled with -DUSE_LTZ=0. This avoid undefined behavior on POSIX platforms. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2022f.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2022f.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2022f.tar.lz The following convenience links are also available, although they may point to the previous release until the relevant caches are refreshed: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit d3dc2a9d65ce433555c994ce2cf84901b87d9357 dated 2022-10-28 18:04:57 -0700 and tagged '2022f' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 3e2ef91b972f1872e3e8da9eae9d1c4638bfdb32600f164484edd7147be45a116db80443cd5ae61b5c34f8b841e4362f4beefd957633f6cc9b7def543ed6752b tzcode2022f.tar.gz 72d05d05be999075cdf57b896c0f4238b1b862d4d0ed92cc611736592a4ada14d47bd7f0fc8be39e7938a7f5940a903c8af41e87859482bcfab787d889d429f6 tzdata2022f.tar.gz 1dd9f8fc3e9fa113a72010b9bceb04c7540b1175801fbd15b591a6bca9400503c6683a4c89f83e08d77f5b78624a005113a8fc428c552a2a4a2b8d26de110141 tzdb-2022f.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmNcfQQACgkQ7ZfpDmKq fjS19A//fGB4YH/GygGQkql4tlshrg7ykQIQCc3qDgBrj09JVeUfM/tAN5unx+lU jBK/V5BK4K9bkrNCmxmhEdoCfdyKqusPLJSrI+ZwqqPXzNOt46dkzUxbRNYH2pvy SZklxSpgJPa4h83I8C3afGOVJn6DYpnv8SKOV6jdOOk8C6aXMaDA6t16BxN1i1Ja UKN9EQtC7xjtvtq7LtLcwo9GMy4pWoyb+CbDayG2wBq4ym3VFLxRbKupVFIDa0I7 +1pzM3Ldg2dwDKvLH8GRzirsisXbfESNVI3v1DmGnm0xDrK5pOT3iPe95OyqvMvL NdjQCpbYpoaUuo8nCf5clU4nzGEDb1sEkI6Mb8tGl2ZgG5gdC5a4P2i20vNmyIt/ uSquD7xmcBZ0CggijpFx0ndZ+0y7XSJNf7mCPaxc7vHCj5jAgQv8HLE6UXChCLeq OazZOW7xEYTDyWQ9xt2HIY1RMVBeaEE5n9V3xyfBQpb/jYeIFm83nEP5X+KjlG0Z 0YGYrVieiwS1lzNTh+LXcXusMwe6B6wYt1G4pVUgasoFADUemfd9y0yzvpdkz6/2 +WvIAF4KbGwdVHteKFR+wq9UyaSFhTUL1f9f+DsYnSbApO4F7KFzDZ3tA9IVLxfy WuOZkqjAtldzkQhoTiygF2cyGwgzWeT1WwNF6oowYYvisDf1o2E= =JtyS -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmNcfQUACgkQ7ZfpDmKq fjRcIBAAhzux6C0XSQtma/RyLPGu18XmXNrFOATZ+pGxZVYEMQCbIwzS5K9yN1eD NqmcyRwI+57Kn4WHIaPcAXepcWq20yv9W30CNAZLmI6bgDlY2x2Hy+N+/TZfGWbQ FKa0gDKh/KMV5efOsgRQDm4RnM81yoJT7CV6abnaAnvUGtOzBlnsnCD5CbEUPA2s RsM/DnHISjofgfRuEyJk1oce/lji4VOaKnoR1u5omUHhOsowAZZs9AVS3dJcYdSc 58QPrwFoZjDtW5SpXV8lufgJBFEaWpDBzgvqwKyZz4SuRmezZLWedhu06iCLNedB ORkL9N5UJj2IXUD46uJGSaFgRyqtAElEzqWjgPsa2HjrTFoDlUfu2+I7HTzE+9ZN JldGwJz3P0ZGYUXldiCsV0dIgVsukcXE+8y2t3XSreTrgY+BQkipCaFz/y9vgMN+ ueudjvcTyTx9K6SCWeZ9UHLGhIPMsTgifmrTi/4Z2O8HHPROtYAF1aAMqKO0qMZ+ YEJnwsyHWDxty+3eB6NXRuvZjAIK3nTf1KUOy5zh4h0oG1/NG19eCNtzLLC3Zpt8 KLXrDPqWU2KRs3ts6l1kYTgiebb0w5iUBksMgTxwcslqYFHQfX++lov0PZOv1Mtl D46ODcN9NAHxsu+MmX9PtAotMVCyyJhhv6sFHnbqzEiA+faHVXw= =E16s -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmNcfQYACgkQ7ZfpDmKq fjT9mA/8CUb7Mz5G+ih1x9HkhqMFE4W8m9C0yQfDL4s3c50HcLIUfjyue0UUejW5 t6Ahs+nkFWXd9l2d0Twp/tRuSMJSuiNkcxcL12zAFD2PmP1gjmvObup56jNlOSut RzuCjhDCcNablZUCFnPJ7RtZ3CDfB4wQlp86QsELFhRyhOEIpp+dtPbJ6rRQctMt 8E3Bdk5CvmMrtosTWMRJRDP6e3ox1Dx1idUSFwTedHaxwpFw7edVyuS6rV5i7i3G hX+9osS1fxV7uLJ7dEd78Hlg55ygn2l5iaxyl7bEWnBpRjGjeuYzir34Y7ddWoKh 2feE4z1aG8zIzXJMCnojqiyFO4Thsm1naWKwBLzIx0L3y09NOtRAL/9HYbO4f0Zi /owClbYLQSjzqaVLxFfSscFt9iIwonmQsynG3/aJuNAHQVEXhAWg5dlaEqG0pCLo mKsvg8aeu5sC68bokEZbsGzcPnmQYFTnhU9ZXYvEIrCbBUuszv7FdlSsB6Jwwhqn dadNZF5mToxUSp6YfmwTY/STvf6WJOxMuU2bxF4Bi79xptY8mO2tEre/wamwId95 Vk0aNyFD8z9PJu8Sfk5cPijJXLcGI6MEXoZlJ9Ou9l/Ybio9Ns4YH7tjHf8O10Uu 9QM3XMKKyAG2G49mYbU1lJDmcM1VGtGmS/CibmL/d1eZdNFTBqw= =Eezp -----END PGP SIGNATURE-----

5 6

checklinks.awk validation too strict
by Stephen Colebourne Oct. 30, 2022

Oct. 30, 2022

Hi, The latest version of checklinks.awk includes the following check: if (backcheck && FILENAME != backcheck && $3 != "GMT") { printf "%s: Link should be in '%s'\n", $3, backcheck status = 1 } The effect of the check is to insist that all Links are in the backward file. I understand this makes sense for TZDB's default dataset, as it now contains no Links in the main set of data files. In my opinion however it is perfectly valid to have a Link in the main set of files. This has been long-standing practice for TZDB. We know that some downstream consumers edit the source files before compiling them, so it seems highly likely that someone will still be wanting to have a Link in one of the main files. (And no, I don't think a command line option to turn it off is the right solution. If the check needs retaining there should be a "strict" mode only used by the default TZDB dataset) In summary, I think that this check should be removed since it is complaining about perfectly valid input files. thanks Stephen

2 1

Country heading for Morocco missing
by Stephen Colebourne Oct. 30, 2022

Oct. 30, 2022

I've noticed that the comment that acts as a heading for Morocco in the `africa` file is now missing. It is around line 591. I believe it was erroneously deleted. thanks Stephen

2 1

2022f and zonetab entries for Mexico
by Chris Walton Oct. 30, 2022

Oct. 30, 2022

According to 2022f, *America/Chihuahua* and *America/Ojinaga* switched from Mountain Time to Central Time. The descriptions in zone.tab and zone1970.tab still show "Mountain Time". -chris

3 5

[PROPOSED] Don’t assume nonempty argv
by Paul Eggert Oct. 29, 2022

Oct. 29, 2022

Don’t dump core if argv[0] is NULL, which is allowed on GNU/Linux if the invoker is sufficiently perverse. * zdump.c (progname): Now char const *, so that it can be given the address of a string constant. (tzalloc): Use optarg, not progname, since progname’s type is no longer correct. * zdump.c, zic.c (main): Initialize progname to non-null. --- zdump.c | 6 +++--- zic.c | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/zdump.c b/zdump.c index 512ba8cc..f0461ade 100644 --- a/zdump.c +++ b/zdump.c @@ -84,7 +84,7 @@ static time_t const absolute_max_time = ? (((time_t) 1 << atime_shift) - 1 + ((time_t) 1 << atime_shift)) : -1); static int longest; -static char * progname; +static char const *progname; static bool warned; static bool errout; @@ -234,7 +234,7 @@ tzalloc(char const *val) exit(EXIT_FAILURE); } tzset(); - return &progname; /* Any valid non-null char ** will do. */ + return &optarg; /* Any valid non-null char ** will do. */ # else enum { TZeqlen = 3 }; static char const TZeq[TZeqlen] = "TZ="; @@ -463,7 +463,7 @@ main(int argc, char *argv[]) # endif /* defined TEXTDOMAINDIR */ textdomain(TZ_DOMAIN); #endif /* HAVE_GETTEXT */ - progname = argv[0]; + progname = argv[0] ? argv[0] : "zdump"; for (i = 1; i < argc; ++i) if (strcmp(argv[i], "--version") == 0) { printf("zdump %s%s\n", PKGVERSION, TZVERSION); diff --git a/zic.c b/zic.c index 501718f4..f3b32ecc 100644 --- a/zic.c +++ b/zic.c @@ -943,7 +943,7 @@ main(int argc, char **argv) textdomain(TZ_DOMAIN); #endif /* HAVE_GETTEXT */ main_argv = argv; - progname = argv[0]; + progname = argv[0] ? argv[0] : "zic"; if (TYPE_BIT(zic_t) < 64) { fprintf(stderr, "%s: %s\n", progname, _("wild compilation-time specification of zic_t")); -- 2.37.2

4 5

[PROPOSED] Most of Mexico will no longer observe DST
by Paul Eggert Oct. 29, 2022

Oct. 29, 2022

Also, Chihuahua moves to year-round -06. * NEWS: Mention this. * northamerica (Mexico): No DST after 2022. (America/Ojinaga, America/Chihuahua): Switch from -07 to -06 on 2022-10-30 02:00. --- NEWS | 9 +++++++++ northamerica | 20 ++++++++++++++++---- 2 files changed, 25 insertions(+), 4 deletions(-) diff --git a/NEWS b/NEWS index 331c1d2..5689811 100644 --- a/NEWS +++ b/NEWS @@ -3,6 +3,8 @@ News for the tz database Unreleased, experimental changes Briefly: + Mexico will no longer observe DST except near the US border. + Chihuahua moves to year-round -06 on 2022-10-30. Fiji no longer observes DST. Move links to 'backward'. In vanguard form, GMT is now a Zone and Etc/GMT a link. @@ -16,6 +18,13 @@ Unreleased, experimental changes Changes to future timestamps. + Mexico will no longer observe DST after 2022, except for areas + near the US border that continue to observe US DST rules. + On 2022-10-30 at 02:00 the Mexican state of Chihuahua moves + from -07 (-06 with DST) to year-round -06, thus not changing + its clocks that day. The new law states that Chihuahua + near the US border no longer observes US DST. + Fiji will not observe DST in 2022/3. (Thanks to Shalvin Narayan.) For now, assume DST is suspended indefinitely. diff --git a/northamerica b/northamerica index 1f16a1c..df19543 100644 --- a/northamerica +++ b/northamerica @@ -2553,6 +2553,12 @@ Zone America/Dawson -9:17:40 - LMT 1900 Aug 20 # 5- The islands, reefs and keys shall take their timezone from the # longitude they are located at. +# From Paul Eggert (2022-10-28): +# The new Mexican law was published today: +# https://www.dof.gob.mx/nota_detalle.php?codigo=5670045&fecha=28/10/2022 +# This abolishes DST except where US DST rules are observed, +# and in addition changes all of Chihuahua to -06 with no DST. + # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule Mexico 1931 only - May 1 23:00 1:00 D Rule Mexico 1931 only - Oct 1 0:00 0 S @@ -2568,8 +2574,8 @@ Rule Mexico 1996 2000 - Apr Sun>=1 2:00 1:00 D Rule Mexico 1996 2000 - Oct lastSun 2:00 0 S Rule Mexico 2001 only - May Sun>=1 2:00 1:00 D Rule Mexico 2001 only - Sep lastSun 2:00 0 S -Rule Mexico 2002 max - Apr Sun>=1 2:00 1:00 D -Rule Mexico 2002 max - Oct lastSun 2:00 0 S +Rule Mexico 2002 2022 - Apr Sun>=1 2:00 1:00 D +Rule Mexico 2002 2022 - Oct lastSun 2:00 0 S # Zone NAME STDOFF RULES FORMAT [UNTIL] # Quintana Roo; represented by Cancún Zone America/Cancun -5:47:04 - LMT 1922 Jan 1 6:00u @@ -2622,7 +2628,8 @@ Zone America/Ojinaga -6:57:40 - LMT 1922 Jan 1 7:00u -6:00 Mexico C%sT 1998 -6:00 - CST 1998 Apr Sun>=1 3:00 -7:00 Mexico M%sT 2010 - -7:00 US M%sT + -7:00 US M%sT 2022 Oct 30 2:00 + -6:00 - CST # Chihuahua (away from US border) Zone America/Chihuahua -7:04:20 - LMT 1922 Jan 1 7:00u -7:00 - MST 1927 Jun 10 23:00 @@ -2631,7 +2638,8 @@ Zone America/Chihuahua -7:04:20 - LMT 1922 Jan 1 7:00u -6:00 - CST 1996 -6:00 Mexico C%sT 1998 -6:00 - CST 1998 Apr Sun>=1 3:00 - -7:00 Mexico M%sT + -7:00 Mexico M%sT 2022 Oct 30 2:00 + -6:00 - CST # Sonora Zone America/Hermosillo -7:23:52 - LMT 1922 Jan 1 7:00u -7:00 - MST 1927 Jun 10 23:00 @@ -2729,6 +2737,10 @@ Zone America/Tijuana -7:48:04 - LMT 1922 Jan 1 7:00u # http://dof.gob.mx/nota_detalle.php?codigo=5127480&fecha=06/01/2010 # It has been moved to the 'backward' file. # +# From Paul Eggert (2022-10-28): +# Today's new law states that the entire state of Baja California +# follows US DST rules, which agrees with simplifications noted above. +# # # Revillagigedo Is # no information -- 2.37.3

1 0

Daylight Savings Time in Fiji Islands
by Shalvin Narayan Oct. 28, 2022

Oct. 28, 2022

Hi Contributors, Please note that there will not be any daylight savings time change in Fiji for 2022-2023. As per current tzdata, the time is scheduled to be changed on 13 November and moved back on 15 January. However, as per the government announcement, it will not be the case and they have canceled the DST change. You can find the announcement on: https://www.facebook.com/FijianGovernment/posts/pfbid0mmWVTYmTibn66ybpFda75… Requesting if the updated tzdata package can be provided so the patch can be implemented in the system and reflected in global time and data systems. zdump -v Pacific/Fiji | grep 2022 zdump: warning: zone "Pacific/Fiji" abbreviation "+12" lacks alphabetic at start Pacific/Fiji Sat Jan 15 13:59:59 2022 UTC = Sun Jan 16 02:59:59 2022 +13 isdst=1 gmtoff=46800 Pacific/Fiji Sat Jan 15 14:00:00 2022 UTC = Sun Jan 16 02:00:00 2022 +12 isdst=0 gmtoff=43200 Pacific/Fiji Sat Nov 12 13:59:59 2022 UTC = Sun Nov 13 01:59:59 2022 +12 isdst=0 gmtoff=43200 Pacific/Fiji Sat Nov 12 14:00:00 2022 UTC = Sun Nov 13 03:00:00 2022 +13 isdst=1 gmtoff=46800 zdump -v Pacific/Fiji | grep 2023 zdump: warning: zone "Pacific/Fiji" abbreviation "+12" lacks alphabetic at start Pacific/Fiji Sat Jan 14 13:59:59 2023 UTC = Sun Jan 15 02:59:59 2023 +13 isdst=1 gmtoff=46800 Pacific/Fiji Sat Jan 14 14:00:00 2023 UTC = Sun Jan 15 02:00:00 2023 +12 isdst=0 gmtoff=43200 Pacific/Fiji Sat Nov 11 13:59:59 2023 UTC = Sun Nov 12 01:59:59 2023 +12 isdst=0 gmtoff=43200 Pacific/Fiji Sat Nov 11 14:00:00 2023 UTC = Sun Nov 12 03:00:00 2023 +13 isdst=1 gmtoff=46800 timedatectl status Local time: Wed 2022-10-26 16:19:46 +12 Universal time: Wed 2022-10-26 04:19:46 UTC RTC time: Wed 2022-10-26 04:19:47 Time zone: Pacific/Fiji (+12, +1200) NTP enabled: yes NTP synchronized: yes RTC in local TZ: no DST active: no Last DST change: DST ended at Sun 2022-01-16 02:59:59 +13 Sun 2022-01-16 02:00:00 +12 Next DST change: DST begins (the clock jumps one hour forward) at Sun 2022-11-13 01:59:59 +12 Sun 2022-11-13 03:00:00 +13 Thanks Shalvin Narayan Head of ICT Telecom Fiji Limited [cidimage002.png(a)01D70F67.132FB220] P: (679) 321 0247 M: (679) 991 3793 This email (including any attachments) is confidential and intended solely for the use of the recipient it is addressed to. It may also be subject to legal or other professional privileges. Information contained in this email should not be copied or forwarded without the consent of the sender. If you have received this transmission in error, please notify the sender immediately and destroy and/or delete all hard and soft data relating to this transmission. Confidentiality or privilege is not waived or lost because this email has been sent to you by mistake. Telecom Fiji Limited has active anti-virus measures on its email systems but does not accept any liability in connection with any computer virus, data corruption, delay, interruption, unauthorized access, or unauthorized amendment. Any views expressed in this email are those of the individual sender, except where expressly stated to be a representation by Telecom Fiji Limited

3 3

Wrong day light savings (DST) in Syria
by MAHMAOD RADWAN Oct. 28, 2022

Oct. 28, 2022

Dear iana organization Right now in Syria government made a decision to cancel day light saving (DST) in Syria but for some reason smartphones (android and ios) devices reserve a change to it clock so the clock in the all smartphones are now late for an hour so I hope to fix this mistake and reasove the issue Note i live right now in Syria and my clock is late for an hour

4 4

[PROPOSED 1/7] Avoid undefined behavior if no Link lines
by Paul Eggert Oct. 28, 2022

Oct. 28, 2022

* zic.c (make_links): Don't call qsort(NULL, 0, ...) as this has undefined behavior in C. This fixes a bug introduced five days ago. --- zic.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/zic.c b/zic.c index 78afa67..a699285 100644 --- a/zic.c +++ b/zic.c @@ -683,7 +683,8 @@ static void make_links(void) { ptrdiff_t i, j, nalinks; - qsort(links, nlinks, sizeof *links, qsort_linkcmp); + if (nlinks) + qsort(links, nlinks, sizeof *links, qsort_linkcmp); /* Ignore each link superseded by a later link with the same name. */ j = 0; -- 2.37.3

9 33

[PROPOSED] Fix recently-introduced zic infloop
by Paul Eggert Oct. 28, 2022

Oct. 28, 2022

* zic.c (make_links): Diagnose link cycles instead of looping. --- zic.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/zic.c b/zic.c index 4222869..501718f 100644 --- a/zic.c +++ b/zic.c @@ -688,7 +688,7 @@ bsearch_linkcmp(void const *key, void const *b) static void make_links(void) { - ptrdiff_t i, j, nalinks; + ptrdiff_t i, j, nalinks, pass_size; if (1 < nlinks) qsort(links, nlinks, sizeof *links, qsort_linkcmp); @@ -700,7 +700,7 @@ make_links(void) i++; links[j++] = links[i]; } - nlinks = j; + nlinks = pass_size = j; /* Walk through the link array making links. However, if a link's target has not been made yet, append a copy to the @@ -739,8 +739,22 @@ make_links(void) eat(links[i].l_filenum, links[i].l_linenum); /* If this pass examined all its links, start the next pass. */ - if (i == j) + if (i == j) { + if (nalinks - i == pass_size) { + error(_("\"Link %s %s\" is part of a link cycle"), + links[i].l_target, links[i].l_linkname); + break; + } j = nalinks; + pass_size = nalinks - i; + } + + /* Diagnose self links, which the cycle detection algorithm would not + otherwise catch. */ + if (strcmp(links[i].l_target, links[i].l_linkname) == 0) { + error(_("link %s targets itself"), links[i].l_target); + continue; + } /* Make this link unless its target has not been made yet. */ l = bsearch(links[i].l_target, &links[i + 1], j - (i + 1), -- 2.37.3

1 0

[PROPOSED 1/2] Don’t include <sys/type.h>
by Paul Eggert Oct. 27, 2022

Oct. 27, 2022

* private.h: Do not include <sys/types.h> for time_t. Including sys/types.h was added on 1989-04-10 to support pre-C89 platforms, but this is no longer needed now that we assume C89. --- private.h | 1 - 1 file changed, 1 deletion(-) diff --git a/private.h b/private.h index ffb9d48..baacdfb 100644 --- a/private.h +++ b/private.h @@ -179,7 +179,6 @@ #undef tzfree #include <stddef.h> -#include <sys/types.h> /* for time_t */ #include <string.h> #include <limits.h> /* for CHAR_BIT et al. */ #include <stdlib.h> -- 2.37.3

1 1

[PROPOSED] Fix zdump undefined behavior if !USE_LTZ
by Paul Eggert Oct. 27, 2022

Oct. 27, 2022

When compiled with -DUSE_LTZ=0, zdump modified pointers in the environ vector, which POSIX says results in undefined behavior. Fix this by using setenv if available, otherwise by arranging for the modifications to occur to the vector before it's assigned or re-assigned to ‘environ’. * Makefile, NEWS: Mention this. * private.h (HAVE_SETENV): Default to 1. * zdump.c (tzalloc): If HAVE_SETENV, just use setenv; it’s simpler. Otherwise, avoid modifying environ, environ[0], environ[0][0], etc. while environ is in use by getenv etc. Do this by keeping two independent environ vectors; the original one and fakeenv. If !HAVE_SETENV, return the initial environ array. (tzalloc, tzfree): Give the getenv family a chance of getting the correct answer, by calling tzset after each time the environment is modified. (tzfree): Restore the initial environ array. --- Makefile | 1 + NEWS | 4 ++++ private.h | 4 ++++ zdump.c | 57 ++++++++++++++++++++++++++++++++++++++----------------- 4 files changed, 49 insertions(+), 17 deletions(-) diff --git a/Makefile b/Makefile index d3cfbd0..34cec49 100644 --- a/Makefile +++ b/Makefile @@ -223,6 +223,7 @@ LDLIBS= # -DHAVE_MALLOC_ERRNO=0 if malloc etc. do not set errno on failure. # -DHAVE_POSIX_DECLS=0 if your system's include files do not declare # functions like 'link' or variables like 'tzname' required by POSIX +# -DHAVE_SETENV=0 if your system lacks the setenv function # -DHAVE_SNPRINTF=0 if your system lacks the snprintf function # -DHAVE_STDINT_H if you have a non-C99 compiler with <stdint.h>* # -DHAVE_STRFTIME_L if <time.h> declares locale_t and strftime_l diff --git a/NEWS b/NEWS index a918aed..546fe11 100644 --- a/NEWS +++ b/NEWS @@ -73,6 +73,10 @@ Unreleased, experimental changes releases have been out of support since 2019. This change affects only fat TZif files, as thin files never had the workaround. + zdump no longer modifies the environ vector when compiled on + platforms lacking tm_zone or when compiled with -DUSE_LTZ=0. + This avoid undefined behavior on POSIX platforms. + Release 2022e - 2022-10-11 11:13:02 -0700 diff --git a/private.h b/private.h index 2c7535d..ffb9d48 100644 --- a/private.h +++ b/private.h @@ -87,6 +87,10 @@ # define HAVE_POSIX_DECLS 1 #endif +#ifndef HAVE_SETENV +# define HAVE_SETENV 1 +#endif + #ifndef HAVE_STRDUP # define HAVE_STRDUP 1 #endif diff --git a/zdump.c b/zdump.c index 168f72a..ffb321a 100644 --- a/zdump.c +++ b/zdump.c @@ -228,33 +228,56 @@ mktime_z(timezone_t tz, struct tm *tmp) static timezone_t tzalloc(char const *val) { +# if HAVE_SETENV + if (setenv("TZ", val, 1) != 0) { + perror("setenv"); + exit(EXIT_FAILURE); + } + tzset(); + return NULL; +# else + enum { TZeqlen = 3 }; + static char const TZeq[TZeqlen] = "TZ="; static char **fakeenv; - char **env = fakeenv; - char *env0; - if (! env) { - char **e = environ; - int to; + static size_t fakeenv0size; + void *freeable = NULL; + char **env = fakeenv, **initial_environ; + size_t valsize = strlen(val) + 1; + if (fakeenv0size < valsize) { + char **e = environ, **to; + ptrdiff_t initial_nenvptrs; /* Counting the trailing NULL pointer. */ while (*e++) continue; - env = xmalloc(sumsize(sizeof *environ, - (e - environ) * sizeof *environ)); - to = 1; - for (e = environ; (env[to] = *e); e++) - to += strncmp(*e, "TZ=", 3) != 0; + initial_nenvptrs = e - environ; + fakeenv0size = sumsize(valsize, valsize); + fakeenv0size = max(fakeenv0size, 64); + freeable = env; + fakeenv = env = + xmalloc(sumsize(sumsize(sizeof *environ, + initial_nenvptrs * sizeof *environ), + sumsize(TZeqlen, fakeenv0size))); + to = env + 1; + for (e = environ; (*to = *e); e++) + to += strncmp(*e, TZeq, TZeqlen) != 0; + env[0] = memcpy(to + 1, TZeq, TZeqlen); } - env0 = xmalloc(sumsize(sizeof "TZ=", strlen(val))); - env[0] = strcat(strcpy(env0, "TZ="), val); - environ = fakeenv = env; + memcpy(env[0] + TZeqlen, val, valsize); + initial_environ = environ; + environ = env; tzset(); - return env; + free(freeable); + return initial_environ; +# endif } static void -tzfree(timezone_t env) +tzfree(timezone_t initial_environ) { - environ = env + 1; - free(env[0]); +# if !HAVE_SETENV + environ = initial_environ; + tzset(); +# endif } #endif /* ! USE_LOCALTIME_RZ */ -- 2.37.3

1 0

[PROPOSED 1/2] Default time_t to 64 bits on glibc 2.34+ 32-bit
by Paul Eggert Oct. 26, 2022

Oct. 26, 2022

* NEWS: Mention this. * private.h (_TIME_BITS): Default to 64. --- NEWS | 8 ++++++++ private.h | 12 ++++++++++-- 2 files changed, 18 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index bddbd3da..a918aed2 100644 --- a/NEWS +++ b/NEWS @@ -57,6 +57,14 @@ Unreleased, experimental changes number 2438 comes from the 32-bit limit in the year 2038, plus the 400-year Gregorian cycle. (Problem reported by Bradley White.) + On glibc 2.34 and later, which optionally supports 64-bit time_t + on platforms like x86 where time_t was traditionally 32 bits, + default time_t to 64 instead of 32 bits. This lets functions like + localtime support timestamps after the year 2038, and fixes + year-2038 problems in zic when accessing files dated after 2038. + To continue to limit time_t to 32 bits on these platforms, use + "make CFLAGS='-D_TIME_BITS=32'". + In C code, prefer C23 keywords to pre-C23 macros for alignof, bool, false, and true. Also, use the following C23 features if available: __has_include, unreachable. diff --git a/private.h b/private.h index c185d5f3..2c7535d8 100644 --- a/private.h +++ b/private.h @@ -127,8 +127,9 @@ /* Enable strtoimax on pre-C99 Solaris 11. */ #define __EXTENSIONS__ 1 -/* To avoid having 'stat' fail unnecessarily with errno == EOVERFLOW, - enable large files on GNUish systems ... */ +/* Although tzcode does not call 'stat'-like functions directly, stdio + functions may call them. To avoid having them fail unnecessarily + with errno == EOVERFLOW, enable large files on GNUish systems ... */ #ifndef _FILE_OFFSET_BITS # define _FILE_OFFSET_BITS 64 #endif @@ -137,6 +138,13 @@ /* ... and enable large inode numbers on Mac OS X 10.5 and later. */ #define _DARWIN_USE_64_BIT_INODE 1 +/* On GNUish systems where time_t might be 32 or 64 bits, use 64. + This supports a wider time range, and avoids having 'stat'-like + functions fail unnecessarily with errno == EOVERFLOW. */ +#ifndef _TIME_BITS +# define _TIME_BITS 64 +#endif + /* ** Nested includes */ -- 2.37.2

1 1

Re: [tz] tz Digest, Vol 133, Issue 32
by richa＠msn.com Oct. 24, 2022

Oct. 24, 2022

Once again, "All problems in computer science can be solved by another level of indirection." ________________________________ From: tz <tz-bounces(a)iana.org> on behalf of tz-request(a)iana.org <tz-request(a)iana.org> Sent: Monday, October 24, 2022 7:00 AM To: tz(a)iana.org <tz(a)iana.org> Subject: tz Digest, Vol 133, Issue 32 Send tz mailing list submissions to tz(a)iana.org To subscribe or unsubscribe via the World Wide Web, visit https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.… or, via email, send a message with subject or body 'help' to tz-request(a)iana.org You can reach the person managing the list at tz-owner(a)iana.org When replying, please edit your Subject line so it is more specific than "Re: Contents of tz digest..."

1 0

[PROPOSED 1/2] zic now supports links to links
by Paul Eggert Oct. 24, 2022

Oct. 24, 2022

* NEWS, backward, zic.8: Mention this. * zic.c (make_links): New function, which supports links to later links. In this function, improve quality of warnings about links to links. (main): Use it. --- NEWS | 14 ++++++++ backward | 6 ++-- zic.8 | 29 ++++++++++++++--- zic.c | 97 ++++++++++++++++++++++++++++++++++++++++++++++++-------- 4 files changed, 126 insertions(+), 20 deletions(-) diff --git a/NEWS b/NEWS index 64a2d0c..f400d71 100644 --- a/NEWS +++ b/NEWS @@ -5,6 +5,7 @@ Unreleased, experimental changes Briefly: Move links to 'backward'. In vanguard form, GMT is now a Zone and Etc/GMT a link. + zic now supports links to links. Simplify four Ontario zones into one. Fix a Y2438 bug when reading TZif data. @@ -28,6 +29,19 @@ Unreleased, experimental changes Changes to code + zic now supports links to links regardless of input line order. + For example, if Australia/Sydney is a Zone, the lines + Link Australia/Canberra Australia/ACT + Link Australia/Sydney Australia/Canberra + now work correctly, even though the shell commands + ln Australia/Canberra Australia/ACT + ln Australia/Sydney Australia/Canberra + would fail because the first command attempts to use a link + Australia/Canberra that does not exist until after the second + command is executed. Previously, zic had unspecified behavior if + a Link line's target was another link, and zic often misbehaved if + a Link line's target was a later Link line. + Fix line number in zic's diagnostic for a link to a link. Fix a bug that caused localtime to mishandle timestamps starting diff --git a/backward b/backward index 101cbc0..4c1c5d5 100644 --- a/backward +++ b/backward @@ -17,9 +17,9 @@ # backward compatibility link. Each section is sorted by link name. # A "#= TARGET1" comment labels each link inserted only because some -# .zi parsers mishandle links to links. The comment says what the -# target would be if these parsers were fixed so that data could -# contain links to links. For example, the line +# .zi parsers (including tzcode through 2022e) mishandle links to links. +# The comment says what the target would be if these parsers were fixed +# so that data could contain links to links. For example, the line # "Link Australia/Sydney Australia/ACT #= Australia/Canberra" would be # "Link Australia/Canberra Australia/ACT" were it not that data lines # refrain from linking to links like Australia/Canberra, which means diff --git a/zic.8 b/zic.8 index e46d0ab..f79148f 100644 --- a/zic.8 +++ b/zic.8 @@ -190,7 +190,10 @@ the named file rather than in the standard location. Be more verbose, and complain about the following situations: .RS .PP -The input specifies a link to a link. +The input specifies a link to a link, +something not supported by some older parsers, including +.B zic +itself through release 2022e. .PP A year that appears in a data file is outside the range of representable years. @@ -691,19 +694,37 @@ The .B TARGET field should appear as the .B NAME -field in some zone line. +field in some zone line or as the +.B LINK-NAME +field in some link line. The .B LINK-NAME field is used as an alternative name for that zone; it has the same syntax as a zone line's .B NAME field. +Links can chain together, although the behavior is unspecified if a +chain of one or more links does not terminate in a Zone name. +A link line can appear before the line that defines the link target. +For example: +.sp +.ne 3 +.nf +.in +2m +.ta \w'Zone\0\0'u +\w'Greenwich\0\0'u +Link Greenwich G_M_T +Link Etc/GMT Greenwich +Zone Etc/GMT\0\00\0\0\*-\0\0GMT +.sp +.in +.fi +The two links are chained together, and G_M_T, Greenwich, and Etc/GMT +all name the same zone. .PP Except for continuation lines, lines may appear in any order in the input. However, the behavior is unspecified if multiple zone or link lines -define the same name, or if the source of one link line is the target -of another. +define the same name. .PP The file that describes leap seconds can have leap lines and an expiration line. diff --git a/zic.c b/zic.c index 82e1a4d..78afa67 100644 --- a/zic.c +++ b/zic.c @@ -678,6 +678,89 @@ bsearch_linkcmp(void const *key, void const *b) return strcmp(key, m->l_linkname); } +/* Make the links specified by the Link lines. */ +static void +make_links(void) +{ + ptrdiff_t i, j, nalinks; + qsort(links, nlinks, sizeof *links, qsort_linkcmp); + + /* Ignore each link superseded by a later link with the same name. */ + j = 0; + for (i = 0; i < nlinks; i++) { + while (i + 1 < nlinks + && strcmp(links[i].l_linkname, links[i + 1].l_linkname) == 0) + i++; + links[j++] = links[i]; + } + nlinks = j; + + /* Walk through the link array making links. However, + if a link's target has not been made yet, append a copy to the + end of the array. The end of the array will gradually fill + up with a small sorted subsequence of not-yet-made links. + nalinks counts all the links in the array, including copies. + When we reach the copied subsequence, it may still contain + a link to a not-yet-made link, so the process repeats. + At any given point in time, the link array consists of the + following subregions, where 0 <= i <= j <= nalinks and + 0 <= nlinks <= nalinks: + + 0 .. (i - 1): + links that either have been made, or have been copied to a + later point point in the array (this later point can be in + any of the three subregions) + i .. (j - 1): + not-yet-made links for this pass + j .. (nalinks - 1): + not-yet-made links that this pass has skipped because + they were links to not-yet-made links + + The first subregion might not be sorted if nlinks < i; + the other two subregions are sorted. This algorithm does + not alter entries 0 .. (nlinks - 1), which remain sorted. + + If there are L links, this algorithm is O(C*L*log(L)) where + C is the length of the longest link chain. Usually C is + short (e.g., 3) though its worst-case value is L. */ + + j = nalinks = nlinks; + + for (i = 0; i < nalinks; i++) { + struct link *l; + + eat(links[i].l_filenum, links[i].l_linenum); + + /* If this pass examined all its links, start the next pass. */ + if (i == j) + j = nalinks; + + /* Make this link unless its target has not been made yet. */ + l = bsearch(links[i].l_target, &links[i + 1], j - (i + 1), + sizeof *links, bsearch_linkcmp); + if (!l) + l = bsearch(links[i].l_target, &links[j], nalinks - j, + sizeof *links, bsearch_linkcmp); + if (!l) + dolink(links[i].l_target, links[i].l_linkname, false); + else { + /* The link target has not been made yet; copy the link to the end. */ + links = growalloc (links, sizeof *links, nalinks, &nlinks_alloc); + links[nalinks++] = links[i]; + } + + if (noise && i < nlinks) { + if (l) + warning(_("link %s targeting link %s mishandled by pre-2023 zic"), + links[i].l_linkname, links[i].l_target); + else if (bsearch(links[i].l_target, links, nlinks, sizeof *links, + bsearch_linkcmp)) + warning(_("link %s targeting link %s"), + links[i].l_linkname, links[i].l_target); + } + } +} + /* Simple signal handling: just set a flag that is checked periodically outside critical sections. To set up the handler, prefer sigaction if available to close a signal race. */ @@ -992,19 +1075,7 @@ _("%s: invalid time range: %s\n"), continue; outzone(&zones[i], j - i); } - /* - ** Make links. - */ - if (noise) - qsort(links, nlinks, sizeof *links, qsort_linkcmp); - for (i = 0; i < nlinks; ++i) { - eat(links[i].l_filenum, links[i].l_linenum); - dolink(links[i].l_target, links[i].l_linkname, false); - if (noise - && bsearch(links[i].l_target, links, nlinks, sizeof *links, - bsearch_linkcmp)) - warning(_("link to link")); - } + make_links(); if (lcltime != NULL) { eat(COMMAND_LINE_FILENUM, 1); dolink(lcltime, tzdefault, true); -- 2.37.3

1 1

Pacific islands as identifiers
by Paul-Cathy Unger Oct. 22, 2022

Oct. 22, 2022

Hi, I was recently setting the time zone on my computer to my current location -- Honiara, Solomon Islands. In my operating system's drop-down list of "Cities" (I use a Linux distro based on Ubuntu), I could not find Honiara. I finally ended up clicking on the map approximately where I thought it would be. To my surprise, where I clicked had the label "Guadalcanal". I wasn't expecting that, and certainly wasn't looking for Guadalcanal in the list -- Honiara would have made a lot more sense to me (e.g., https://www.timeanddate.com/time/zone/solomon-islands) I'm wondering what the rationale is for using island / province names for some Pacific nations and city names for others (e.g., Apia, Samoa; Port Moresby, PNG)? And I wonder if knowing that there are historic animosities in a country between people from one island and another would be enough to consider changing an apparent favouring of one island over another? For a brief and somewhat current analysis, see https://www.csis.org/analysis/deep-roots-solomon-islands-ongoing-political-…. I offer this for your kind consideration, Paul Unger

2 1

[PROPOSED 1/7] Port better to C23 bool
by Paul Eggert Oct. 20, 2022

Oct. 20, 2022

* private.h (HAVE_STDBOOL_H): Remove. (true, false, bool): Simply rely on __STDC_VERSION__. There’s no longer need to treat pre-C99 compilers with <stdbool.h> specially, as they can be treated as if they lack <stdbool.h>. --- Makefile | 1 - NEWS | 3 +++ private.h | 10 +++------- 3 files changed, 6 insertions(+), 8 deletions(-) diff --git a/Makefile b/Makefile index 156840e..afe7af7 100644 --- a/Makefile +++ b/Makefile @@ -223,7 +223,6 @@ LDLIBS= # -DHAVE_POSIX_DECLS=0 if your system's include files do not declare # functions like 'link' or variables like 'tzname' required by POSIX # -DHAVE_SNPRINTF=0 if your system lacks the snprintf function -# -DHAVE_STDBOOL_H if you have a non-C99 compiler with <stdbool.h> # -DHAVE_STDINT_H if you have a non-C99 compiler with <stdint.h> # -DHAVE_STRFTIME_L if <time.h> declares locale_t and strftime_l # -DHAVE_STRDUP=0 if your system lacks the strdup function diff --git a/NEWS b/NEWS index 164ab95..16f454c 100644 --- a/NEWS +++ b/NEWS @@ -37,6 +37,9 @@ Unreleased, experimental changes number 2438 comes from the 32-bit limit in the year 2038, plus the 400-year Gregorian cycle. (Problem reported by Bradley White.) + Take advantage of the following C23 features if available: + bool/true/false keywords. + Release 2022e - 2022-10-11 11:13:02 -0700 diff --git a/private.h b/private.h index 9c31ec5..058d3c0 100644 --- a/private.h +++ b/private.h @@ -74,10 +74,6 @@ # define HAVE_POSIX_DECLS 1 #endif -#ifndef HAVE_STDBOOL_H -# define HAVE_STDBOOL_H (199901 <= __STDC_VERSION__) -#endif - #ifndef HAVE_STRDUP # define HAVE_STRDUP 1 #endif @@ -623,12 +619,12 @@ time_t time2posix_z(timezone_t, time_t) ATTRIBUTE_PURE; ** Finally, some convenience items. */ -#if HAVE_STDBOOL_H -# include <stdbool.h> -#else +#if __STDC_VERSION__ < 199901 # define true 1 # define false 0 # define bool int +#elif __STDC_VERSION__ < 202311 +# include <stdbool.h> #endif #define TYPE_BIT(type) (sizeof(type) * CHAR_BIT) -- 2.37.3

1 6

[PATCH 0/5] Simplifying Link line maintenance
by Paul Eggert Oct. 17, 2022

Oct. 17, 2022

Although TZDB currently puts most Link lines in the ‘backward’ file, some Link lines reside in the continental files ‘africa’, ‘antarctica’, etc., with little rhyme or reason as to which lines are in ‘backward’ and which line are in a continental file. This is confusing and makes maintenance a bit more difficult. This proposed series of patches aims to regularize this by putting the Link lines into ‘backward’, except that to work around a TZUpdater bug the GMT Link line is in ‘backward’ only when using vanguard form. As part of these patches, the Link lines in ‘backward’ are organized into sections that better explain the reason for each Link line. Also, comments are added to document shortcut Link lines, that is, Link lines reworded to reference the target rather than the source of another Link line. Furthermore, the Makefile is augmented to check Link lines more carefully. The overall effect of this patch is to shrink TZDB’s source code and make maintenance simpler and more robust, without affecting data except for users who are purposely bleeding-edge by omitting all backward-compatibility links. Because these patches are nontrivial I have not installed them in the development repository, and there is no rush. Comments welcome as usual. Paul Eggert (5): Move a few links to ‘backward’ Move most remaining links to ‘backward’ Reorder 'backward’ Improve checking for shortcut links Coalesce some commentary Makefile | 6 +- NEWS | 17 +++ africa | 213 ++++++++++-------------------------- antarctica | 2 +- asia | 69 ++++-------- australasia | 46 +++----- backward | 288 +++++++++++++++++++++++++++++++++++++++---------- checklinks.awk | 17 +++ etcetera | 17 ++- europe | 202 ++++++++++++---------------------- northamerica | 86 ++++----------- southamerica | 15 --- theory.html | 1 + zdump.c | 4 +- ziguard.awk | 14 +++ 15 files changed, 472 insertions(+), 525 deletions(-) -- 2.37.3

2 8

Re: [tz] Northern Ontario (Canada)
by dpatte Oct. 17, 2022

Oct. 17, 2022

Individual reserves usually have their own names such as the one near Fort Frances, "Nigigoonsiminikaaning" (Little Otters Playing). If the whole treaty area followed a rule than I agree that the treaty name would be a good solution. ----- Original Message ----- From: Brian Inglis via tz [mailto:tz@iana.org] To: <tz(a)iana.org> Sent: Sat, 15 Oct 2022 17:35:27 -0600 Subject: Re: [tz] Northern Ontario (Canada) Hi folks, Given that ids are named for the largest municipality observing given rules, and those named municipalities are not documented as nor likely to have diverged from provincial rules, then applying those ids to rural areas, especially reserves, would be erroneous. In the case of Canadian rural reserves, large areas are normally covered by the federal treaties under which those settlements were negotiated, and if reserves in those treaty areas could be documented to have ignored DST, then perhaps better ids would be e.g. Treaty3 for the ON Lake of the Woods Area, and Treaty60 for the ON Nipigon Lake area, given that other applicable labels are likely to be either confusing, excessively long, or require uncommon fonts to render? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry On 2022-10-15 17:02, Chris Walton via tz wrote: > Paul, > The changes look correct except that you linked *America/Rainy_River* to > *America/Toronto* instead of *America/Winnipeg*. > Rainy River is west of 90°W and needs to remain on Central Time. > > David, > I don't deny that there may have been some small reserves that did not observe > daylight saving. > They could still be added to the database if somebody wants to do the research > and provide appropriate names. > However, it would be wrong to use the names of existing towns and cities to > represent small reserves that exist outside of those towns and cities. > > -chris > > On Sat, 15 Oct 2022 at 17:11, dpatte <dpatte(a)relativedata.com > <mailto:dpatte@relativedata.com>> wrote: > > My concern about these changes is that I seem to remember that some first > nations in those areas did not use daylight-savings time on their reserves, > and that they were real but very small 'zones', not the large zones they > ended up being assumed to be. > > Unfortunately I have no documentation either way on this. > > > *----- Original Message -----* > *From:* Paul Eggert via tz [mailto:tz@iana.org] <mailto:tz@iana.org> > *To:* "Chris Walton" <crj.walton(a)gmail.com <mailto:crj.walton@gmail.com>> > *Cc:* tz(a)iana.org <mailto:tz@iana.org> > *Sent:* Sat, 15 Oct 2022 12:53:28 -0700 > *Subject:* Re: [tz] Northern Ontario (Canada) > > Thank you for doing that investigative work. Proposed patch attached and > installed into the tzdb development repository on GitHub. > > This patch follows your suggestions, except that it moves Nipigon's and > Rainy River's dubious data to 'backzone' instead of removing them > entirely, as I worry that some users will want the appearance of > completeness no matter how illusory.

2 1

Re: [tz] Northern Ontario (Canada)
by dpatte Oct. 16, 2022

Oct. 16, 2022

My concern about these changes is that I seem to remember that some first nations in those areas did not use daylight-savings time on their reserves, and that they were real but very small 'zones', not the large zones they ended up being assumed to be. Unfortunately I have no documentation either way on this. ----- Original Message ----- From: Paul Eggert via tz [mailto:tz@iana.org] To: "Chris Walton" <crj.walton(a)gmail.com> Cc: tz(a)iana.org Sent: Sat, 15 Oct 2022 12:53:28 -0700 Subject: Re: [tz] Northern Ontario (Canada) Thank you for doing that investigative work. Proposed patch attached and installed into the tzdb development repository on GitHub. This patch follows your suggestions, except that it moves Nipigon's and Rainy River's dubious data to 'backzone' instead of removing them entirely, as I worry that some users will want the appearance of completeness no matter how illusory.

4 3

Northern Ontario (Canada)
by Chris Walton Oct. 15, 2022

Oct. 15, 2022

On January 1, 1970, the twin cities of Fort William and Port Arthur were merged to form the City of Thunder Bay. The TZ database currently shows that Thunder Bay has observed daylight saving every year from 1970 onwards with the exception of 1973. Back in July I raised some doubts on this mailing list about the 1973 data. I now have more proof that it is wrong. Somebody from the Thunder Bay Public Library was kind enough to send me two newspaper scans from 1973. Both scans are from the Chronicle Journal which has been a local Thunder Bay newspaper since 1972. *Chronicle Journal - Saturday April 28, 1973 - page 1* This page contains a slightly corny but very relevant notice titled "*Clocks Move Ahead Sunday*''. It reads: > Advancing an hour glass one hour for daylight saving time appears to pose > a problem for Pat Plachta. She knows DST begins at 2 a.m. Sunday and she'll > have one less hour to sleep in the morning but she'll make it up in the > Fall. Above the article is a picture of a woman holding an hourglass. Being that this is a Thunder Bay newspaper, the implication is that Thunder Bay did observe daylight saving in 1973. For completeness, I will also mention that the same newspaper page also contains a generic Canadian Press article titled "*Canadians Will Lose Hour Sleep*". The article briefly documents daylight saving practices across the country with no mention of any specific towns or cities. It starts out with: > OTTAWA (CP) — 12:01 a.m. becomes 1:01 a.m. in Canada Sunday. ... Clearly that first line is not entirely correct because most (but not all) of Canada was doing the switch at 2:00a.m. instead of 12:01a.m. I am not quoting the entire article here because it is not specific to Thunder Bay and there is nothing in it that we do not already know. *Chronicle Journal - Saturday October 27, 1973 - page 1* This page contains a notice titled "*Extra Sleep*". It reads: > Tonight city residents can look forward to gaining an extra hour of rest, > as Thunder Bay goes from Daylight Saving Time to Eastern Standard Time. So > don't forget to set your clocks back an hour tonight at 12:01 a.m. I will assume that 12:01 is an error; since most cities and towns in Ontario switched at 2:00a.m. Regardless, the notice provides additional proof that Thunder Bay did observe daylight saving in 1973. The TZ database entry for *America/Thunder_Bay* should be updated to include the observance of daylight saving in 1973. This change will make *America/Thunder_Bay* identical to *America/Toronto* from October 26, 1969 until present. Ultimately, *America/Thunder_Bay *could be replaced with a link. It could also be maintained in the backzone file using pre-1970 history from either Port Arthur or Fort William. Both Port Arthur and Fort William started their first experiments with daylight saving on May 2, 1908 which is not currently reflected in the *America/Thunder_Bay* data. Unfortunately I do not have a complete history for Port Arthur or Fort William however there are a couple of sources to start with: https://www.thunderbay.ca/en/inc/blog.aspx (scroll to the bottom) http://www.bayviewmagazine.com/article/2022/03/great-springing-forward-deba… Also, I would also like to see *America/Nipigon *and* America/Rainy_River* converted into link entries because I have zero faith in the current Shanks based data. America/Nipigon --> America/Toronto America/Rainy_River --> America/Winnipeg I am not convinced it is worth saving the data for either of these two questionable zones inside the backzone file. As I pointed out in July, the TZ database shows that Nipigon started daylight saving in 1974, but newspaper evidence shows it was already using daylight saving at least as far back as 1972. https://news.ourontario.ca/npl/122271/page/2 And FYI: The *America/Nipigon* and *America/Rainy_River* boundaries were removed from OpenStreetMap back in August. The *America/Toronto* boundary was restored to include most of Ontario east of 90°W. I was happy to see it done. -chris

2 1

time keeps on slipping into the future
by Bradley White Oct. 15, 2022

Oct. 15, 2022

tzfile.5 says: > After the second header and data comes a newline-enclosed, > POSIX-TZ-environment-variable-style string for use in handling > instants after the last transition time stored in the file I had imagined that the reference implementation would apply the future rule for all of the future, but I currently observe that UTC-offset changes get stuck after a while for many (but not all) zones. For example, for *"Australia/Sydney"*, whose POSIX TZ string is *"AEST-10AEDT,M10.1.0,M4.1.0/3"*, tz_localtime_rz() produces the following civil times at the given instants: 14745254399 = 2437-04-05T02:59:59+1100 14745254400 = 2437-04-05T02:00:00+1000 14760979199 = 2437-10-04T01:59:59+1000 14760979200 = 2437-10-04T03:00:00+1100 That looks good ... daylight time from the first Sunday in Oct through the first Sunday in Apr, shifting at 03:00. But once we hit 2438, the UTC offset is stuck at +1100. For example, in July we would expect to see standard time, but instead get: 14784296400 = 2438-07-01T00:00:00+1100 And it never seems to recover after that. I'm pretty sure this used to work.

2 8