- tz - lists.iana.org

[PROPOSED 0/6] Fix integer overflows and drop posixrules
by Paul Eggert Jan. 17, 2026

Jan. 17, 2026

GitHub user Naveed8951 reported a potential (but unlikely) security flaw due to undefined behavior in localtime.c after integer overflow. The patches in this series should fix the reported problems. Some of the problem occurred in a part of the localtime.c code that was implementing a feature declared obsolete in TZDB release 2019b. This feature let the sysadmin specify default DST rules for DST-but-ruleless old-style POSIX settings like TZ="AST4ADT". Rather than try to fix the feature this patch series removes it; the feature is hardly ever used and would stop working in 2038 anyway. As a result, tzcode by default uses current US DST for these settings, with no opportunity for sysadmin override (though the default can be overriden when tzcode is compiled). This behavior is already common elsewhere. Paul Eggert (6): Add comment re UT offsets equal to -2**31 Document zic -p better zic now warns about -p Remove POSIXRULES installation option Remove TZDEFRULES ("posixrules") from localtime.c Fix remaining Naveed8951-reported overflows Makefile | 28 +--- NEWS | 19 +++ localtime.c | 388 ++++++++++++++++++++++++---------------------------- newctime.3 | 4 +- newtzset.3 | 29 +--- tzfile.5 | 7 +- tzfile.h | 12 +- zic.8 | 17 ++- zic.c | 8 ++ 9 files changed, 228 insertions(+), 284 deletions(-) -- 2.52.0

1 6

Unable to find Doha in the database
by Paul Menzel Jan. 15, 2026

Jan. 15, 2026

Dear Time Zone Database folks, Visiting Doha, I wanted to change to its time zone, and knowing `Europe/Berlin`, I looked for *Doha*, but didn’t find it in GNOME [1]. Looking through the Time Zone Database archive, there is in `asia` [3]: # Bahrain # Qatar # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Asia/Qatar 3:26:08 - LMT 1920 # Al Dawhah / Doha 4:00 - %z 1972 Jun 3:00 - %z The comment is not in my file on Debian though in `/usr/share/zoneinfo/tzdata.zi` from *tzdata* 2025c-3. Z Asia/Qatar 3:26:8 - LMT 1920 4 - %z 1972 Jun 3 - %z Of course, I do not know, if the comment would change anything. Would it be possible to also add Qatar’s capital to the database. Or is there another way to make it easier for people to find the right time zone entry? Kind regards, Paul [1]: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/3656 [2]: https://github.com/eggert/tz/blob/d5f71488fd1ec4a2f7166ceeac2024a677daaaef/…

3 2

[PROPOSED 0/5] Fix some unlikely undefined behaviors
by Paul Eggert Jan. 12, 2026

Jan. 12, 2026

This patchest fixes some bugs in localtime.c when TZif files specify a UT offset equal to -2**31. Such an offset overflows when negated on a 32-bit platform, and this leads to undefined behavior – typically wraparound arithmetic, but the C standard says anything can happen. The patchset also changes zic.c to reject attempts to create such an offset, adjusts some nearby code to be a bit cleaner and more portable. Paul Eggert (5): Omit unnecessary L suffixes zic no longer generates utoff == -2**31 Make sure 2**31 - 1 is signed Port TWOS_COMPLEMENT to signed-magnitude hosts Disallow UT offsets equal to -2**31 NEWS | 4 ++++ localtime.c | 48 ++++++++++++++++++++++++++++++++---------------- private.h | 7 +++++-- strftime.c | 5 +++-- zic.c | 7 ++++--- 5 files changed, 48 insertions(+), 23 deletions(-) -- 2.51.0

1 5

[PROPOSED] Improve .gitignore patterns
by Paul Eggert Jan. 10, 2026

Jan. 10, 2026

* .gitignore: Ignore all subdirectories. Also ignore *.bak, *.core, *.out, *.t, core, and core.*. Also ignore .*, except for .gitignore itself. --- .gitignore | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/.gitignore b/.gitignore index e7bb0416..5a140b46 100644 --- a/.gitignore +++ b/.gitignore @@ -1,26 +1,38 @@ # Files intentionally not tracked by Git. # This file is in the public domain. +# +# Ignore all subdirectories. +*/ +# +# Ignore non-directories that are the output of builds, +# or are backups or nonces unlikely to be added to the repository. *.a *.asc +*.bak *.ck -*.ckd/ +*.core *.diff -*.dir/ *.i *.o *.orig +*.out *.patch *.pdf *.ps *.rej *.s +*.t *.tar *.tar.* *.txt *.tzs *.zi *~ +.* +!.gitignore ChangeLog +core +core.* date leapseconds tzdir.h -- 2.51.0

1 0

Whither /usr/share/zoneinfo/right?
by Paul Gilmartin Jan. 8, 2026

Jan. 8, 2026

ISTR on Linux long ago, a subdirectory, /usr/share/zoneinfo/right, which used arguments not POSIX time but TAI. Was that a local hack, or was it removed, possibly because of uncertainty of future leap seconds? -- Thanks, gil

4 5

Fwd: Bulletin C number 71
by Tim Parenti Jan. 7, 2026

Jan. 7, 2026

No leap second 2026-06-30, per below. See attached patch. -- Tim Parenti ---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc(a)obspm.fr> Date: Tue, 6 Jan 2026 at 06:50 Subject: Bulletin C number 71 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, 06 January 2026 Bulletin C 71 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 2026. 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

2 1

static_assert macro
by Christos Zoulas Jan. 7, 2026

Jan. 7, 2026

Hello, The new tzcode uses static_assert() with no message which is a c2x extension. clang does not like that by default (without specifying -std=gnu2x). /home/source/ab/HEAD-llvm/src/lib/libc/time/private.h:1017:52: error: '_Static_assert' with no message is a C2x extension [-Werror,-Wc2x-extensions] || TIME_T_MAX >> (TYPE_BIT(time_t) - 2) == 1); ^ , "" Best, christos

3 4

tzcode and tzdata tar base make checks fail
by Brian Inglis Dec. 31, 2025

Dec. 31, 2025

Cygwin uses separate packages of tzcode programs and tzdata files verbatim to support standard local time zones in preference to limited native data. Running make check on the separate tar file fails in both cases. When I took over the packages, I provided basic checks, but reviewed and changed the builds this release, and would like to reenable the built in checks you provide and mentioned recently. The attached logs show the results of having the package build scripts run `make check` from the package build directory which is set up with symlinks to each of the tar sources. Is there anything obviously missing or incorrect with `make check` invocations which could cause the observed failures, or things that may need changed? -- 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 à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry

2 6

Time zones on Antarctica expedition
by Brooks Harris Dec. 30, 2025

Dec. 30, 2025

Those who have a New York Times subscription may find this entertaining: Does Anybody Really Know What Time It Is? The clocks aboard our icebreaker will be changed several times en route to Antarctica. It’s one of many things that make the expedition feel otherworldly. https://www.nytimes.com/2025/12/29/climate/antarctica-time-zone.html

1 0

[PROPOSED] Fix some unsequenced/reproducible commentary
by Paul Eggert Dec. 21, 2025

Dec. 21, 2025

* private.h (ATTRIBUTE_CONST, ATTRIBUTE_PURE): In commentary do not say that __attribute__((const)) is stricter than [[unsequenced]], as Jens Gustedt, an originator of [[unsequenced]], wrote in <https://lists.gnu.org/r/bug-gnulib/2025-01/msg00190.html> that some const functions are not unsequenced. To be safe, make a similar change for __attribute__((pure)) and [[reproducible]], though I don’t have confirmation from Jens. --- private.h | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/private.h b/private.h index 074da284..50d6a52a 100644 --- a/private.h +++ b/private.h @@ -619,11 +619,11 @@ typedef unsigned long uintmax_t; # define ATTRIBUTE_UNSEQUENCED /* empty */ #endif -/* GCC attributes that are useful in tzcode. - __attribute__((const)) is stricter than [[unsequenced]], - so the latter is an adequate substitute in non-GCC C23 platforms. - __attribute__((pure)) is stricter than [[reproducible]], - so the latter is an adequate substitute in non-GCC C23 platforms. */ +/* GNU C attributes that are useful in tzcode. + Although neither __attribute__((const)) nor __attribute__((pure)) are + stricter than their C23 counterparts [[unsequenced]] and [[reproducible]], + the C23 attributes happen to work in each tzcode use of ATTRIBUTE_CONST + and ATTRIBUTE_PURE. (This might not work outside of tzcode!) */ #if __GNUC__ < 3 # define ATTRIBUTE_CONST ATTRIBUTE_UNSEQUENCED # define ATTRIBUTE_FORMAT(spec) /* empty */ -- 2.51.0

2 5