public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Adolf Belka <adolf.belka@ipfire.org>
To: development@lists.ipfire.org
Cc: Adolf Belka <adolf.belka@ipfire.org>
Subject: [PATCH] tzdata: Update to version 2026f
Date: Thu, 29 Oct 2026 14:34:34 +0100	[thread overview]
Message-ID: <20261029133434.3222358-8-adolf.belka@ipfire.org> (raw)
In-Reply-To: <20261029133434.3222358-1-adolf.belka@ipfire.org>

- Update from version 2026e to 2026f
- No change in rootfile
- Changelog
2026f
  Briefly:
    Cuba will not fall back 2026-11-01; stays on -04 through 2027-11-07.
    No more leap seconds, and leap second tables no longer expire.
    Improve 1965/1966 data for Brazil.
  Changes to future timestamps
    Cuba will not fall back to -05 on 2026-11-01 and instead plans to
     maintain -04 through 2027-11-07.
  Changes to past timestamps
    In 1965 Brazil ended DST on 03-31 at 24:00 not 00:00, and in 1966
     it ended DST on 03-01 at 01:00 not 00:00.  (Thanks to Daniel Dias
     Rodrigues.)
  Changes to code
    zic now ignores Expires lines, as leap second tables in TZif files
     no longer expire now that there are no more leap seconds;
     see Internet RFC 9636 §3.2.  (Thanks to Garrett Wollman for the
     heads-up re no more leap seconds.)
    localtime.c no longer supports 49 leap seconds, as 27 now suffice.
     zic now warns if you go over the new limit.
    A new compile-time flag -DMIN_TRANSITION_GAP=N specifies a minimum
     transition gap of N seconds when reading TZif files.  It currently
     defaults to 0, but can be set to 1 if TZif files generated by zic
     2021b and earlier are no longer of concern.
    With 32-bit time_t, localtime.c functions now check for transition
     ordering in TZif data as carefully as they do with 64-bit time_t.
     (Problem reported by Ana Bobillo.)
    On platforms like FreeBSD that have O_RESOLVE_BENEATH but lack
     O_REGULAR, localtime.c compiled with -DOPENAT_TZDIR now checks
     that a TZ setting with ".." components names a regular file
     before opening it in an unprivileged program, as it already did
     for other settings that might name a file outside TZDIR.
     This fixes a bug introduced in 2026c.  (Thanks to Ana Bobillo.)
  Changes to documentation and commentary
    Documentation and commentary now reflect leap seconds’ demise.
  Changes to commentary
    Discussion on timekeeping in northwestern Ontario has been updated
     to reflect that provincial regulation has been issued to allow these
     areas to stay aligned with America/Winnipeg and follow Manitoba’s
     adoption of year-round -05 after all.  (Thanks to Aoun Khan,
     Chris Walton, and Heitor David Pinto.)
    Discussion on timekeeping in Saskatchewan has been updated to
     document its new Time Act, 2026 which comes into force on
     2026-10-30.  (Thanks to Heitor David Pinto.)  No change is expected.

Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
---
 lfs/tzdata | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lfs/tzdata b/lfs/tzdata
index 1dda8489b..b30016374 100644
--- a/lfs/tzdata
+++ b/lfs/tzdata
@@ -24,7 +24,7 @@
 
 include Config
 
-VER        = 2026e
+VER        = 2026f
 # https://data.iana.org/time-zones/releases/.tar.gx & .asc
 
 TZDATA_VER = $(VER)
@@ -47,8 +47,8 @@ objects = tzdata$(TZDATA_VER).tar.gz tzcode$(TZCODE_VER).tar.gz
 tzdata$(TZDATA_VER).tar.gz = $(DL_FROM)/tzdata$(TZDATA_VER).tar.gz
 tzcode$(TZCODE_VER).tar.gz = $(DL_FROM)/tzcode$(TZCODE_VER).tar.gz
 
-tzdata$(TZDATA_VER).tar.gz_BLAKE2 = 0669a6189c1d9f4adbf7b2ed6778d1d48b7799db4e86d60d9ff275dcd635341f1d0325141e0b792c4472e38d7f9f60e81cbb0142a35a98a7b169351afbed9daf
-tzcode$(TZCODE_VER).tar.gz_BLAKE2 = 3265ce424251a83179fb5523b770f3c7fc5d6c5b7267fa4cf08e416d79f83117f8a581bde1d2ba57122852bbdaef08742bab478705ab135dfdf2ddc1b5743d9f
+tzdata$(TZDATA_VER).tar.gz_BLAKE2 = eb7ca7804c69d3dd63767644fb5061ebd1c396c9a6946c8dae47fc5b190f50da6e3ede6476fb90cbf9ac2689f91fc3c5d20151a03482f5cb4e519dda7842bf1a
+tzcode$(TZCODE_VER).tar.gz_BLAKE2 = 4305d696e4adb01749fcde0f4bf96a7fd650ad44c9345858a5fefc23c7a6057f2b077de67b6d64c17bef56c9b13425c707d1fa182ce6e57b531d5a1cd4c929dd
 
 install : $(TARGET)
 
-- 
2.56.0



      parent reply	other threads:[~2026-10-29 13:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-29 13:34 [PATCH] cmake: Update to version 4.4.4 Adolf Belka
2026-10-29 13:34 ` [PATCH] core206: Ship cmake Adolf Belka
2026-10-29 13:34 ` [PATCH] core206: Ship lvm2 Adolf Belka
2026-10-29 13:34 ` [PATCH] core206: Ship lzip Adolf Belka
2026-10-29 13:34 ` [PATCH] core206: Ship tzdata Adolf Belka
2026-10-29 13:34 ` [PATCH] lvm2: Update to version 2.03.44 Adolf Belka
2026-10-29 13:34 ` [PATCH] lzip: Update to version 1.26 Adolf Belka
2026-10-29 13:34 ` Adolf Belka [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261029133434.3222358-8-adolf.belka@ipfire.org \
    --to=adolf.belka@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox