- tz - lists.iana.org

- tz - lists.iana.org
Keyboard Shortcuts
Thread View
: Next unread message
: Previous unread message
j a
: Jump to all threads
j l
: Jump to MailingList overview
tz
Threads by
month
----- 2026 -----
April
March
February
January
----- 2025 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2024 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2023 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2022 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2021 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2020 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2019 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2018 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2017 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2016 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2015 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2014 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2013 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2012 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2011 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2010 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2009 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2008 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2007 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2006 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2005 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2004 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2003 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2002 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2001 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 2000 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 1999 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 1998 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 1997 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 1996 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 1995 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 1994 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 1993 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 1992 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 1991 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 1990 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 1989 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 1988 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 1987 -----
December
November
October
September
August
July
June
May
April
March
February
January
----- 1986 -----
December
November
tz@iana.org
10 participants
7500 discussions
Alberta to follow British Columbia?
by Roozbeh Pournader
April 23, 2026
April 23, 2026
I just ran into this:
[PROPOSED] Check for NEWS typos similar to 2026b’s
by Paul Eggert
April 23, 2026
April 23, 2026
* Makefile (check_mild): Depend on new check.
(news.ck): New check.
* NEWS: Reword to pass check.
---
Makefile | 8 +++++++-
NEWS | 2 +-
2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 1e0a5903..c0dde5be 100644
--- a/Makefile
+++ b/Makefile
@@ -913,7 +913,7 @@ tzselect: tzselect.ksh version
check: check_mild back.ck now.ck
check_mild: check_web check_zishrink \
character-set.ck white-space.ck links.ck mainguard.ck \
- name-lengths.ck slashed-abbrs.ck sorted.ck \
+ name-lengths.ck news.ck slashed-abbrs.ck sorted.ck \
tables.ck ziguard.ck tzs.ck

# True if UTF8_LOCALE does not work;
@@ -1083,6 +1083,12 @@ zishrink-posix.ck zishrink-right.ck: \
rm -fr $@d t-$@d shrunk-$@d
touch $@

+# Check that NEWS has data release versions and dates in reverse order.
+news.ck: NEWS
+ grep '^Release [0-9][0-9][0-9][0-9]' NEWS | LC_ALL=C sort -cru
+ sed -n '/ -0000$$/!s/^Release [^ ]*//p' NEWS|LC_ALL=C sort -cru
+ touch $@
clean_misc:
rm -fr *.ckd *.dir
rm -f *.ck *.core *.o *.out *.t core core.* \
diff --git a/NEWS b/NEWS
index ea52e67e..fb1ced71 100644
--- a/NEWS
+++ b/NEWS
@@ -6666,7 +6666,7 @@ few (e.g., code2012c-data2012d) have tarballs with mixed version
numbers. Recent releases also come in an experimental format
consisting of a single tarball tzdb-R.tar.lz with extra data.

-Release timestamps are taken from the release's commit (for newer,
+A release's timestamp is taken from the release's commit (for newer,
Git-based releases), from the newest file in the tarball (for older
releases, where this info is available) or from the email announcing
the release (if all else fails; these are marked with a time zone
--
2.51.0
[tz-announce] 2026b release of tz code and data available
by Paul Eggert via tz-announce
April 23, 2026
April 23, 2026
The 2026b release of the tz code and data is available. As Tim mentioned
yesterday[1], this release’s main impetus is British Columbia’s decision
to stop changing its clocks and stay on permanent UTC-07, which affects
BC’s UTC offsets starting 2026-11-01 at 02:00. Since this change will
likely cause problems downstream as CLDR’s latest release cannot handle
it, we’re pushing out this release now so that downstream has some time
to test and reprogram. Quite possibly we’ll need another release soon to
accommodate proposed changes in Alberta and Northwest Territories.

[1]:
There is an embarrassing typo in the 2026b release: its NEWS file's
third line has the wrong release number. I applied the following patch
to the development version on GitHub and this patch should appear in the
2026c release.

diff --git a/NEWS b/NEWS
index a0042701..ea52e67e 100644
--- a/NEWS
+++ b/NEWS
@@ -3 +3 @@ News for the tz database
-Release 2026a - 2026-04-22 23:06:43 -0700
+Release 2026b - 2026-04-22 23:06:43 -0700

The 2026b release contains the following changes:

Briefly:
British Columbia moved to permanent -07 on 2026-03-09.
Some more overflow bugs have been fixed in zic.

Changes to future timestamps

British Columbia’s 2026-03-08 spring forward was its last
foreseeable clock change, as it moved to permanent -07 thereafter.
(Thanks to Arthur David Olson.) Although the change to permanent
-07 legally took place on 2026-03-09, temporarily model the change
to occur on 2026-11-01 at 02:00 instead. This works around a
limitation in CLDR v48.2 (2026-03-17). This temporary hack is
planned to be removed after CLDR is fixed.

Changes to code

zic no longer mishandles a last transition to a new time type.

zic no longer overflows a buffer when generating a TZ string like
"PST-167:59:58PDT-167:59:59,M11.5.6/-167:59:59,M12.5.6/-167:59:59",
which can occur with adversarial input. (Thanks to Naveed Khan.)

zic no longer generates a longer TZif file than necessary when
an earlier time zone abbreviation is a suffix of a later one.
As a nice side effect, zic no longer overflows a buffer when given
a long series of abbreviations, each a suffix of the next.
(Buffer overflow reported by Arthur Chan.)

zic no longer overflows an int when processing input like ‘Zone
Ouch 2147483648:00:00 - LMT’. The int overflow can lead to buffer
overflow in adversarial cases. (Thanks to Naveed Khan.)

zic now checks for signals more often.

Here are links to the release files:
The following convenience links are also available, although they may
point to the previous release until the relevant caches are refreshed:
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
48c25a1ba86cb602990c0573aba7795417931bb4 dated 2026-04-22 23:06:43 -0700
and tagged '2026b' in the development GitHub repository at
>.

Here are the SHA-512 checksums for the release files:

55b44d52a83c9db151be32c3d78376ea7f9d4311ef15ed6fe34b855b08fc546531e51309d178d9c175a6d5d7d0b058440e45a55d200ca8925e3798dac9bc739f
tzcode2026b.tar.gz
a44882258c0a7fbe587e8b73d6bb3cd5be7d4788976ea742adbbf176eb3b33e5bd7d1714b2fffe2972b1a42e7335eac39ed0bd63e819bb421550f8cae1df4f2f
tzdata2026b.tar.gz
5ec7f74f14cd2c70a0730e3690e82bd0ba889ac26c96397c16aa08005473c2c86feb47958b52e0301810c8eb908e6d8faf998ffae75b2337a912cc9e52c0f9e9
tzdb-2026b.tar.lz

Here are GPG digital signatures for the release files:

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmnpt34ACgkQ7ZfpDmKq
fjSZew//brt18HiMD/tgxJ1CdjvvzDIZ4P0xWsVuxG4MjkC4821zYCfhDYLZ9Zdb
/8wCi63uecmK2JsGjxzz+raX4ppHhZpg31a70KlyU9MarISVB2ldPqYDn+Xc98lR
XIKj1ahtzyJoNu/67ZbCT7Ih/Wp8hwdlEFivjq00lnt+M2XCeINq9Cy3guisx3/8
dCziZEqoJFXDsdWmCvKZ93U/o7Xq8x7d9nfRjeBlX8VZMXuSnY3WkhLBRl+2Zgml
ECeohhLMBuR6dFNOW6qwlsZGXfDb/Nq1NPsxIKqJ5Lv1K8Sj0h4icsGDMRrLvlZM
qfNpsjWZQcH9JErR5hfB/Y6INRsKomRamul9LdlEAauMwO287eR8r5LrADMiAvPR
jBVqmceAmgS+34BpRmMUfLwQJmEELbK8xzcdW8e41jrQQ8SuyqXQeYBjgjm3v7gc
sA1HyWwDRn6276DQATonELOzREctHLIp2jfRGLAwngAl2CzqkhLZgBEHvdZbqW/s
RbZLOk0u/y3Trd+dyFcLq/gxNSZQYQqpDmRiYNkb0vl02lu3lbZ1o3dmdF/AZ70U
evj6z5iXztdKCQb9ZkecjNXncPDQNPoO1bJqm1QNYvUToMDNnJdu12qva+skNUyt
HE54zxjcKv78bhm2ufXcqt4Ju/onyACTkSDQeCEzIzdBu9abVgw=
=7394
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmnpt34ACgkQ7ZfpDmKq
fjTFTxAAisuje9O4OTkSUUQ4nHuZOHQW/1FNGXmIb/bGnAGAwOrGqiLuyQ0kJYxk
Gdp4cTXEu5+NyQXeBPFtjBNbZO2cMC80rvl9/h3qUlbYG+ydhY0bjDglV3BEP/U/
OrP4pQsNjHeSl+p+3VSq7fAtOGcCRkBQrbEy5yXN5HzYJyCH4GAE1HZNNYKbCzAm
hIxspmu6zjeN4xeLsXrB7DfiP7BJydrxk1LShU4zwmwJdmkH8dCGnDW4Kipz+tWF
2W8P4braXTAWCswLhOC8xYZLJKxf1nWS3dyo3i1IfnRciGD0O9dyLsJmlHxS4/34
Ometm9XahPHPiWvjBoqubKEfp6B+AlmmP9D1jM0BY7seuz2oxFUE7YW5+4cO4VhJ
soWTDCKjyzo+wgflw3brv7j5AFP7tA7To6fbQ0W0oAmSRFQ10MA3JB0GSgn45SST
49C9jQ7U0XcroeIuoWs/1MbAz+qgCLk9QdijxNWsvk5S5h88FKLckVkEUUNgUSL/
F3z4h2Af6KpWq/n3wL97gwdis8cwxWScL3ZpfikiMJbEGuaIHabiw7C+r/dQssW0
7SbG01yZWgn3HtJBfELs1cmqWCUN4F+Y28um0Y4VYHTpSnNuVHBJ1wtfqCSatWYC
wQa+n7KtBEGpY7BbSDZ/oGuqfDzpgR41F1tX7ZRa5y24zWHRQLQ=
=eO2u
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmnpt38ACgkQ7ZfpDmKq
fjTopg//ViAbiWmRZnu7F5owFRPySQWCSM1RJfBWOTL/UJjSArP2JbkOudcgeXZo
Wj6fk1soY8w3o6CJACq12HhUAjQq6/mCupTyDSgOETMn2x/ZknuE407MOMc0t51t
iYnfICJNYs1u1uRC/b7PEALYT7lt3Ab6QGe5iO2kVrFqJoB1AxRDIQlfPAHiRILY
Abbt9avcL+k76idhSC782BmAFqtogPeHBVYQzBOgw/LfWGQ8ckkk66f4X8E6QMzA
CkDSt/bAWIM/iVKw6ag4VBvIbzY2sR1EieN2GlHj5Dx6xMBlQdDpETgTIfNYG7si
Ndai7vbMh+Gff5JfYiKq94WJ2uAP4jI3phN2NXpcYwc0OmEEMlYc/lcIlje3Bb3o
Y+yop6RoVQpN6zbzLnuCMiDmy1SB2yhWpYQm/bqR1Qsb8vBfWBD3fvdscWXabDl8
m3ii38melVIdjSR18Qf3j9MOXefHo3xu0t00/ppPCwnuKKbhSItvTI9vg8BxqWL8
7iZYhNBkoJTIpgmTaHAggNUKNoa3mNYTuwJr7o/i4Bhki2ggzR5dKiKE9PAXSLaG
1tvCoWVVA3gGklkxFYnUncghC/YbEBDYWlaXbfgOC/+fhix7HnRCNcwckxlww86m
gZCa2DcTBWiVQ6PP/6LzgHgNn7mhriVs0cGGVOlTL/h/zjm5CDw=
=1+mL
-----END PGP SIGNATURE-----
Northwest Territories joining Alberta in plans to scrap seasonal time changes
by Tim Parenti
April 23, 2026
April 23, 2026
"[Northwest Territories] Premier R.J. Simpson announced Monday that the
territory will move to end seasonal time changes and will adopt a
year-round time standard instead."

"Simpson has previously said the territory wouldn't end seasonal time
changes until Alberta does."

Meanwhile, Alberta's proposed change, mentioned yesterday
>,
has yet to be introduced in its Assembly and raises questions about whether
the Regional District of East Kootenay will end up continuing to follow
Alberta or joining the rest of British Columbia.

From the NWT government press release:
"Our government will begin the necessary planning to ensure a smooth
transition here in the Northwest Territories. That includes developing a
clear timeline, working with partners, and giving residents, businesses,
and service providers the time they need to prepare."

--
Tim Parenti
Canada legislative summary as of 2026-04-22
by Tim Parenti
April 23, 2026
April 23, 2026
All,

Paul and I have discussed the recent news out of Alberta and the Northwest
Territories in Canada and how that affects our plans for upcoming releases
of tzdata.
*tl;dr We are inclined to cut a release with the changes for BC shortly,
while we wait for AB and NWT legislation to come through and to determine
where areas such as the Regional District of East Kootenay (Cranbrook, BC)
will land.*

To be clear, we were already aiming to release for BC any day now, but the
recent AB/NWT news did prompt another check and balancing of competing
priorities. A detailed summary of our understanding of where things
currently stand throughout western Canada follows:

*British Columbia*'s premier, David Eby, announced a shift from UTC−8/−7 to
year-round UTC−7 for the bulk of the province (America/Vancouver) on 2
March 2026, pursuant to Order in Council 63 of 2026, joining other areas of
BC (America/Dawson_Creek, America/Fort_Nelson) which had already observed
year-round UTC−7 and are thus unaffected. The order took effect on 9 March
and affects wall clock times from 1 November 2026.

*Alberta*'s premier, Danielle Smith, announced in an interview on Monday 20
April 2026 a planned shift from UTC−7/−6 to year-round UTC−6, aligning the
province (America/Edmonton) with Saskatchewan's long-standing practice,
with legislation to be introduced "this week" as part of an omnibus bill.
Order papers for Alberta's Legislative Assembly suggest the referenced bill
may be Bill 31, the *Red Tape Reduction Statutes Amendment Act, 2026*, but
the Assembly rose before it could be formally introduced today (Wednesday)
so no text is yet available.

Following another sitting tomorrow (Thursday), Alberta's Legislative
Assembly is scheduled to adjourn for a constituency week before sitting
again from 4 to 14 May and then adjourning to late October. So, if the
proposed change is envisioned to take effect from 1 November to imitate BC,
then the bill would likely need to wind its way through the legislative
process within the next few weeks.

*Border areas* within BC, such as most of the Regional District of East
Kootenay (Cranbrook) and eastern portions of the Regional District of
Central Kootenay and the Columbia–Shuswap Regional District, currently
remain with the *status quo* of UTC−7/−6. In particular, RDEK had
previously said on 14 March that it would join the rest of BC on year-round
UTC−7, but walked that back on 10 April while committing to a "public
consultation process". Attached to the agenda for the 10 April RDEK Board
meeting were 189 pages of public comment opposed to the March proposal and
66 pages in support.

Given Alberta's recent announcement, it seems highly likely, then, that the
region will ultimately choose one single year-round time or the other; if
sticking with AB and UTC−6, no new zone would be needed, while if rejoining
BC and UTC−7, a new zone would be needed. Meanwhile, any prolonged
regional inaction could require our action in creating a new zone anyway,
so we will need to keep a close eye on what this area decides and when.
Upcoming RDEK Board meetings are scheduled for 8 May and 12 June.

Similarly, Saskatchewan's *Time Act* may need legislative tweaks to better
handle the area around Lloydminster, which straddles the border between AB
and SK and has thus generally followed Alberta, but here it is much more
reasonable to assume that the end result will ultimately be year-round
UTC−6, once those two provinces are so aligned. Saskatchewan's Legislative
Assembly is presently scheduled to sit until 14 May before similarly
adjourning to late October.
*Northwest Territories*' premier, RJ Simpson, announced later on Monday 20
April 2026 that NWT (represented by America/Edmonton and America/Inuvik)
would follow AB in shifting from UTC−7/−6 to year-round UTC−6, but gave no
specific timeline, stating only that the NWT government will "begin the
necessary planning", which includes "developing a clear timeline [and]
working with partners". Again, assuming this goes forward alongside AB, no
new zone will be needed, but legislative inaction could necessitate
America/Yellowknife becoming its own zone rather than a link.

The NWT Legislative Assembly has committee work scheduled in the next two
weeks, 27 April through 8 May, and next sits from 27 May through 4 June
before also adjourning to late October, so it may be some weeks before
legislative details emerge there.

* * *

In short, because the AB and NWT changes are yet to be legislated and may
take several more weeks to be finalized, it makes sense for us to wait on
those and batch them, so as to also give more time to see how the various
border areas react. Based on legislative calendars, it seems reasonable to
think that any legislation which is to happen in these areas will happen by
mid-June if it is to take effect for November 2026.

In the meantime, a release now-ish with the changes for BC will allow those
to start propagating and downstream vendors/projects to begin grappling
with their various implementation details, including concepts such as
"Pacific Time (US & Canada)" no longer meaning what they once did, before a
follow-up release with AB and NWT changes hopefully by sometime in June
similarly affects additional regions and concepts.

Hopefully this ongoing situation is illustrative as to why we are extremely
hesitant to promise any particular release timing. Any possible forward
guidance we could give would always come with the asterisk "unless
something else comes up".

--
Tim Parenti
[PROPOSED] Output a minimal time zone designation table
by Paul Eggert
April 15, 2026
April 15, 2026
When keeping the time zone designation table small,
also handle the case where an existing abbreviation
is a suffix of the newly arrived abbreviation,
so that only the latter abbreviation needs to be stored.
The only TZif file in the current data affected by this change
is Asia/Ho_Chi_Minh, which shrinks by 4 bytes because
the earlier abbreviation LMT is a suffix of a later one PLMT.
As a nice side effect, this patch also fixes an unlikely stack
buffer overflow reported privately by Arthur Chan.
* NEWS: Mention this.
* zic.c (writezone, addtype):
Handle an abbreviation being added when an existing abbreviation is
its suffix. Without this patch both abbreviations would appear in
this table, but only the longer abbreviation needs to be present.
(checkabbr): New function, containing the checking part
of the old newabbr function.
(newabbr): Remove. Change uses to checkabbr + addabbr.
(addabbr): New function, which is like the old newabbr’s
adding code, except it removes any existing abbreviation
that is a suffix of the new one.
---
NEWS | 6 ++++
zic.c | 110 +++++++++++++++++++++++++++++++++++++++-------------------
2 files changed, 81 insertions(+), 35 deletions(-)

diff --git a/NEWS b/NEWS
index 1a97cbfe..09a15519 100644
--- a/NEWS
+++ b/NEWS
@@ -23,6 +23,12 @@ Unreleased, experimental changes
"PST-167:59:58PDT-167:59:59,M11.5.6/-167:59:59,M12.5.6/-167:59:59",
which can occur with adversarial input. (Thanks to Naveed Khan.)

+ zic no longer generates a longer TZif file than necessary when
+ an earlier time zone abbreviation is a suffix of a later one.
+ As a nice side effect, zic no longer overflows a buffer when given
+ a long series of abbreviations, each a suffix of the next.
+ (Buffer overflow reported by Arthur Chan.)
zic no longer overflows an int when processing input like ‘Zone
Ouch 2147483648:00:00 - LMT’. The int overflow can lead to buffer
overflow in adversarial cases. (Thanks to Naveed Khan.)
diff --git a/zic.c b/zic.c
index 6e859d09..7ecf3b91 100644
--- a/zic.c
+++ b/zic.c
@@ -253,12 +253,13 @@ symlink(char const *target, char const *linkname)
(errno = ENOTSUP, -1)
#endif

-static void check_for_signal(void);
+static int addabbr(char[TZ_MAX_CHARS], int *, char const *);
static void addtt(zic_t starttime, int type);
static int addtype(zic_t, char const *, bool, bool, bool);
-static void leapadd(zic_t, int, int);
static void adjleap(void);
static void associate(void);
+static void checkabbr(char const *);
+static void check_for_signal(void);
static void dolink(const char *, const char *, bool);
static int getfields(char *, char **, int);
static zic_t gethms(const char * string, const char * errstring);
@@ -271,11 +272,11 @@ static void inrule(char ** fields, int nfields);
static bool inzcont(char ** fields, int nfields);
static bool inzone(char ** fields, int nfields);
static bool inzsub(char **, int, bool);
-static int itssymlink(char const *, int *);
static bool is_alpha(char a);
+static int itssymlink(char const *, int *);
+static void leapadd(zic_t, int, int);
static char lowerit(char);
static void mkdirs(char const *, bool);
-static void newabbr(const char * abbr);
static zic_t oadd(zic_t t1, zic_t t2);
static zic_t omul(zic_t, zic_t);
static void outzone(const struct zone * zp, ptrdiff_t ntzones);
@@ -2936,30 +2937,27 @@ writezone(const char *const name, const char *const string, char version,
: i == thisdefaulttype ? old0 : i]
= thistypecnt++;

- for (i = 0; i < sizeof indmap / sizeof indmap[0]; ++i)
- indmap[i] = -1;
thischarcnt = stdcnt = utcnt = 0;
for (i = old0; i < typecnt; i++) {
- register char * thisabbr;
if (omittype[i])
continue;
if (ttisstds[i])
stdcnt = thistypecnt;
if (ttisuts[i])
utcnt = thistypecnt;
- if (indmap[desigidx[i]] >= 0)
- continue;
- thisabbr = &chars[desigidx[i]];
- for (j = 0; j < thischarcnt; ++j)
- if (strcmp(&thischars[j], thisabbr) == 0)
- break;
- if (j == thischarcnt) {
- strcpy(&thischars[thischarcnt], thisabbr);
- thischarcnt += strlen(thisabbr) + 1;
- }
- indmap[desigidx[i]] = j;
+ addabbr(thischars, &thischarcnt, &chars[desigidx[i]]);
+ /* Now that all abbrevs have been added to THISCHARS,
+ it is safe to set INDMAP without worrying about
+ whether the abbrevs might move later. */
+ for (i = 0; i < TZ_MAX_CHARS; i++)
+ indmap[i] = -1;
+ for (i = old0; i < typecnt; i++)
+ if (!omittype[i] && indmap[desigidx[i]] < 0)
+ indmap[desigidx[i]] = addabbr(thischars, &thischarcnt,
+ &chars[desigidx[i]]);
if (pass == 1 && !want_bloat()) {
hicut = thisleapexpiry = false;
pretranstype = -1;
@@ -3782,6 +3780,7 @@ static int
addtype(zic_t utoff, char const *abbr, bool isdst, bool ttisstd, bool ttisut)
register int i, j;
+ int charcnt0;

/* RFC 9636 section 3.2 specifies this range for utoff. */
if (! (-TWO_31_MINUS_1 <= utoff && utoff <= TWO_31_MINUS_1)) {
@@ -3791,12 +3790,18 @@ addtype(zic_t utoff, char const *abbr, bool isdst, bool ttisstd, bool ttisut)
if (!want_bloat())
ttisstd = ttisut = false;

- for (j = 0; j < charcnt; ++j)
- if (strcmp(&chars[j], abbr) == 0)
- break;
- if (j == charcnt)
- newabbr(abbr);
- else {
+ checkabbr(abbr);
+ charcnt0 = charcnt;
+ j = addabbr(chars, &charcnt, abbr);
+ if (charcnt0 < charcnt) {
+ /* If an abbreviation was inserted, increment indexes no
+ earlier than the insert by the size of the insertion,
+ so that they continue to point to the same contents. */
+ for (i = 0; i < typecnt; i++)
+ if (j <= desigidx[i])
+ desigidx[i] += charcnt - charcnt0;
+ } else {
/* If there's already an entry, return its index. */
for (i = 0; i < typecnt; i++)
if (utoff == utoffs[i] && isdst == isdsts[i] && j == desigidx[i]
@@ -4181,10 +4186,8 @@ will not work with pre-2004 versions of zic"));

static void
-newabbr(const char *string)
+checkabbr(char const *string)
- register int i;
if (strcmp(string, GRANDPARENTED) != 0) {
register const char * cp;
const char * mp;
@@ -4203,13 +4206,50 @@ mp = _("time zone abbreviation differs from POSIX standard");
if (mp != NULL)
warning("%s (%s)", mp, string);
- i = strnlen(string, TZ_MAX_CHARS - charcnt) + 1;
- if (charcnt + i > TZ_MAX_CHARS) {
- error(_("too many, or too long, time zone abbreviations"));
- exit(EXIT_FAILURE);
- }
- strcpy(&chars[charcnt], string);
- charcnt += i;
+}
+/* Put into CHS, which currently contains *PNCHS bytes containing
+ NUL-terminated abbreviations none of which are suffixes of another,
+ the abbreviation ABBR including its trailing NUL.
+ If ABBR does not already appear in CHS,
+ possibly as a suffix of an existing abbreviation,
+ add ABBR to CHS, remove from CHS any abbreviation
+ that is a suffix of ABBR, and increment *PNCHS accordingly.
+ Return the index of ABBR after any modifications to CHS are made.
+ If all abbreviations have already been added, this function
+ lets the caller look up the index of an existing abbreviation. */
+static int
+addabbr(char chs[TZ_MAX_CHARS], int *pnchs, char const *abbr)
+{
+ int nchs = *pnchs;
+ int alen = strlen(abbr), nchs_incr = alen + 1;
+ int i;
+ for (i = 0; i < nchs; ) {
+ int clen = strlen(&chs[i]);
+ if (alen <= clen) {
+ /* If ABBR is a suffix of an abbreviation in CHS,
+ return the index of ABBR in CHS. */
+ int isuff = i + (clen - alen);
+ if (memcmp(&chs[isuff], abbr, alen) == 0)
+ return isuff;
+ } else if (memcmp(&chs[i], &abbr[alen - clen], clen) == 0) {
+ /* An abbreviation in CHS is a substring of ABBR.
+ Replace it with ABBR, instead of the more-common
+ actions of appending ABBR or doing nothing. */
+ nchs_incr = alen - clen;
+ break;
+ }
+ i += clen + 1;
+ }
+ if (TZ_MAX_CHARS < nchs + nchs_incr) {
+ error(_("too many, or too long, time zone abbreviations"));
+ exit(EXIT_FAILURE);
+ }
+ memmove(&chs[i + nchs_incr], &chs[i], nchs - i);
+ memcpy(&chs[i], abbr, nchs_incr);
+ *pnchs = nchs + nchs_incr;
+ return i;

/* Ensure that the directories of ARGNAME exist, by making any missing
--
2.53.0
America/Cranbrook
by Chris Walton
April 11, 2026
April 11, 2026
Heads up:

The *Regional District of East Kootenay* is planning to move to year-round
Mountain Standard Time (MST) on November 1, 2026. The district will seek
approval from the province (British Columbia). I am skepitcal that they
really need provincial approval, but I guess there is no harm in seeking it.

In practical terms the district would move from MDT to MST on November 1 as
per usual. After that, the clocks would stay fixed on MST.

Currently most of East Kootenay uses the *America/Edmonton* TZ ID. There
is a very small area in the southwest corner that uses *America/Creston*.
If the change is approved, we would need a new TZ ID... probably something
like "*America/Cranbrook"*.
Columbia-Shuswap Regional District lies to the north of East Kootenay
Regional District. Some areas of Columbia-Shuswap are already on
year-round MST and some areas (including the town of Golden) use MST/MDT.
I would not be surprised if all of Columbia-Shuswap eventually adopts
year-round MST. If that happens, the entire province of BC would be
aligned on year-round MST.

-chris
12
British Columbia will adopt permanent daylight saving time starting March 8, 2026, with no further seasonal clock changes.
by Francis, Jereme
April 10, 2026
April 10, 2026
British Columbia will adopt permanent daylight saving time starting March 8, 2026, with no further seasonal clock changes.

Please ensure this is updated in your database.

Thank you.

Jereme Francis

This email and its attachments are confidential. Any unauthorized use or disclosure is prohibited. If you receive this email in error, please notify me by reply email and permanently delete the original without making any copies or disclosing its contents.
[tz-announce] 2026a release of tz code and data available
by Paul Eggert via tz-announce
April 8, 2026
April 8, 2026
The 2026a release of the tz code and data is available. This release
corrects the time for Moldova's upcoming clock transition on March 29,
as well as on other dates. It also has significant changes to code and
to the build procedure.

This release contains the following changes:

Briefly:
Moldova has used EU transition times since 2022.
The "right" TZif files are no longer installed by default.
-DTZ_RUNTIME_LEAPS=0 disables runtime support for leap seconds.
TZif files are no longer limited to 50 bytes of abbreviations.
zic is no longer limited to 50 leap seconds.
Several integer overflow bugs have been fixed.

Changes to past and future timestamps

Since 2022 Moldova has observed EU transition times, that is, it
has sprung forward at 03:00, not 02:00, and has fallen back at
04:00, not 03:00. (Thanks to Heitor David Pinto.)

Changes to data

Remove Europe/Chisinau from zonenow.tab, as it now agrees with
Europe/Athens for future timestamps.

Changes to build procedure

The Makefile no longer by default installs an alternate set
of TZif files for system clocks that count leap seconds.
Install with 'make REDO=posix_right' to get the old default,
which is rarely used in major downstream distributions.
If your system clock counts leap seconds (contrary to POSIX),
it is better to install with 'make REDO=right_only'.
This change does not affect the leapseconds file, which is still
installed as before.

The Makefile's POSIXRULES option, which was declared obsolete in
release 2019b, has been removed. The Makefile's build procedure
thus no longer optionally installs the obsolete posixrules file.

Changes to code

Compiling with the new option -DTZ_RUNTIME_LEAPS=0 disables
runtime support for leap seconds. Although this conforms to
POSIX, shrinks tzcode's attack surface, and is more efficient,
it fails to support Internet RFC 9636's leap seconds.

zic now can generate, and localtime.c can now use, TZif files that
hold up to 256 bytes of abbreviations, counting trailing NULs.
The previous limit was 50 bytes, and some tzdata TZif files were
already consuming 40 bytes. zic -v warns if it generates a file
that exceeds the old 50-byte limit.

zic -L can now generate TZif files with more than 50 leap seconds.
This helps test TZif readers not limited to 50 leap seconds, as
tzcode's localtime.c is; it has little immediate need for
practical timekeeping as there have been only 27 leap seconds and
possibly there will be no more, due to planned changes to UTC.
zic -v warns if its output exceeds the old 50-second limit.

localtime.c no longer accesses the posixrules file generated by
zic -p. Hence for obsolete and nonconforming settings like
TZ="AST4ADT" it now typically falls back on US DST rules, rather
than attempting to override this fallback with the contents of the
posixrules file. This removes library support that was declared
obsolete in release 2019b, and fixes some undefined behavior.
(Undefined behavior reported by GitHub user Naveed8951.)

The posix2time, posix2time_z, time2posix, and time2posix_z
functions now set errno=EOVERFLOW and return ((time_t) -1) if the
result is not representable. Formerly they had undefined behavior
that could in practice result in crashing, looping indefinitely,
or returning an incorrect result. As before, these functions are
defined only when localtime.c is compiled with the -DSTD_INSPIRED
option.

Some other undefined behavior, triggered by TZif files containing
outlandish but conforming UT offsets or leap second corrections,
has also been fixed. (Some of these bugs reported by Naveed8951.)

localtime.c no longer rejects TZif files that exactly fit in its
internal structures, fixing off-by-one typos introduced in 2014g.

zic no longer generates a no-op transition when
simultaneous Rule and Zone changes cancel each other out.
This occurs in tzdata only in Asia/Tbilisi on 1997-03-30.
(Thanks to Renchunhui for a test case showing the bug.)

zic no longer assumes you can fflush a read-only stream.
(Problem reported by Christos Zoulas.)

zic no longer generates UT offsets equal to -2**31 and localtime.c
no longer accepts them, as they can cause trouble in both
localtime.c and its callers. RFC 9636 prohibits such offsets.

zic -p now warns that the -p option is obsolete and likely
ineffective.

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
dd6be6d1558163517ec55c652efac70842c3b4cc dated 2026-03-01 22:59:49 -0800
and tagged '2026a' in the development GitHub repository at
>.

Here are the SHA3-512 checksums for the release files, generated by
the GNU coreutils 9.8+ command 'cksum -a sha3 -l 512'.

SHA3-512 (tzcode2026a.tar.gz) =
7106762916c6d21aa71fc5b43924582b603e231c90f19fb40ecd81db96208f8a4d6ff9664508c7298c521ab8fed97d4100665f84b2ba17caed04af129e40c5c2
SHA3-512 (tzdata2026a.tar.gz) =
898b090b74d927495a412f382636e4eb2f697e3e357e5a1d35e01cf95f6cdc3bd52533a269ae247b521c6ec1112cbc2df0bb5466accf376e2e7b78a3adde26bd
SHA3-512 (tzdb-2026a.tar.lz) =
5aefc96aa15113da1c30fbba7564636e106e3c0e33f475d48f32c5d3417e945fada548176e56c474a85bf02681e101c7b4dd727eb0053d1d39a81c9a13afe37b

Here are the SHA-512 checksums for the release files:

69a2ad3334ab1491ba349fcd5d3066a26b38ccb59031fec70ca19379cb0514fe2757af7bee31e796913c0cfc322134e2ba16f93ba07fa45cd4a415b9122b2f27
tzcode2026a.tar.gz
407e8e93aaa054a22a4a7d6d8cf480a20630073bf1a00956df16b10318f239a12015de38fad3072249193e314d6fddbff4e74afa40a88f7bf5c9eecc7659ea15
tzdata2026a.tar.gz
1824fc2e198a449ebaa41e6c679a494c486b848f13fe8f18f948fde0533e99f5f01e7e7298e257c565838d24ec743e824f402887abdf525d1ce578a714c71414
tzdb-2026a.tar.lz

Here are GPG digital signatures for the release files:

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmmlNgMACgkQ7ZfpDmKq
fjS64g//TxOxFmBXtJRx4LM8QIL315hvWwVpVAmAk+oFzqjluosfb3xbszBw3fWw
PzcOyQ8PDXV42dq29jO8JjVJkCrvLiBjXWTTV6yDRqp3TEBh5uM4cUormnfcTLkT
bmgVLLmqiNZgZpEHrsQQKaf8Ia/23F2topG0USSzqguLgLBVLcdut8Djfqb5qpqV
xurq88ciC+ZvLENJsBXyfJzN2neuCOelbXgPDz+LJZrv3mJqFrm7EzxHngE8xZ+j
Ny0V6WFaZJisWEif4oGeTPtxQS+LT/2bDBKtNpcFQhvquS6dU0nHHVAvNAIZaGNf
HeQ/LgxFDQjnIisoqKA61qNmZZ1F5rDuYtL/j53nhjJpLkaDAoEU+xfKtYybJzir
mH7Dj8WwUcLwH7lT/U4KDZmiUiT49Vk/u/7+pI1Vx7OogJ4Vs9WTtCt8avNGkwFF
qez91hNIb6iZzVbnSKz+TWlfnBgltFQU02ozTZNW6K3TawLuwgyMoAGX0kaK8Lxy
8KKEo53phmmFnZ9vQKEJkJdaaIuisK1qJH1K6cj2GX44bhpDfT/kq4AQQbR7HDWR
ZSTB5oG4TvqfGd3bKrDzpGOOLJ2AoiBaGi+rcA8n4WWvdGxodIJ6RU1cDI+RHPfv
8caWfWcEtAPCciArx2pa10gupda67DF1pwxAYLEbr+dmg2S8jQI=
=/yto
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmmlNgMACgkQ7ZfpDmKq
fjR04A//YmSFvKQi/w8hfB5fAf4VSV+5HBIeuTRJPn9BuRAUvZVYl78ApYGzSqPh
sG3H/IPprHICVxMJcPBvEI7+tXVPozCOnwUx7jz2nAvl7awxj5n2z1zs+jjZ+/pU
kiQ4x4uZDJTw5wsymy9nPasoQba5kmSItjB7fDXe2wwjPOh3osOzSfC0KDnPvTxl
jPxBTd+CXDmz5fiI7RPSi1uJWJFXEtE+NpaltQpA8J1M7QSv2O+7x3eLfNoa1Eh9
GQ5JjtvMixdQGxFzMeID/Y2Rjj3vKFpB0+blf1zu5aBchemmvW/DFpOBhdm+lRf0
Me1TVlmlBI3oj4lrNhGIz3f7zf+IrPVfAAQ/hMMcyYc/FwYuuV9SSF0Aj2pWR0Mi
wvASEXb23bWu2t1aeu7by7XSnL033o1P5DqWDueVSilTdeVSOS0EtyyFMC6THmj4
PcQh7/O60zbPhsUXan85rOC1CNv9lZJlEzZShy3B3tAccGr4IKrPRT/jIhVwVbu9
rS25dLR9S/bcrYTpn4aaWMPQ9tuYJ/83i1euAgs7NjKao0lziPTOPaBvqW6fdg1v
/4dHluvwMufDLa23WVy2iPueTPD8NDH228xwrtGm/Spyu3XCX7YZJdCJVcNF0E9m
W4z5R07LGBZYKscd9T8otPJyzTLcunLmnaf/Mbsrj4FmB+dNof8=
=SR0V
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmmlNgQACgkQ7ZfpDmKq
fjRfhg//WKsUlkhd9treq8Q3YMju7fezVZhvinFib7mmC3kn3HM5Xo2AKakjtwYn
d0ZDuA886qFp3Llkn3pwnEh8vugE0A86qRwk3D3RoL/QfpbKkrVyAWONEWCHMKF1
MswUEO01Lcxd+CmjFWsH+dEhJ8HHLlPgyYgWCy6X3zvTyCLK5navq93QTmIKBguy
tXAtWClft7wEv4Sg6xI0MtcAMamt5aBP9oC284XJbjfHz169QcK5VaCJPG82kuDs
ABorgc6KVJN88SzPWsajpEQQE17hsH99y+Jh4UR4Lx4s06+52zOl814t0Aru28B2
K8u0PF5mO3druoHN8ielp9gdqIMk5JbOobhezGmnNPQT2ZIazTBa22/zVknkqoLq
6NQnpPekc2sjuVljRYCRkDwWXaUYfl8gR7e59Ew45IfFBpRCfkpEFK4A97KGfGVM
gSCdW/N+9lCG2p1MrrRETykyGCX181rtnw8RXO+ADxmz8ddQ5WRrmGIkBYi7iocY
2iULltrLOAzCnUGsN0x/7xk8fLf7MRX+cExUJG992foiPQ/6N/06gp6SNeJyuKgG
hI5TO9RIsR8JzjfUpI0Nbr9ZwkQuLFfkvvXSZeYwVU4rFNEHaQqz4dVvcfTAwi1T
9AK8S/7FjRoh/aqbUe9rVsUAOUcoOAkgCd2bUkcYLQ8FXJqJPYA=
=t0qu
-----END PGP SIGNATURE-----
B.C. Permanent Daylight Savings
by Matthew Lee
April 6, 2026
April 6, 2026
Hello, will this database be updating for B.C. switching permanently to Daylight Savings Time? Thank you.