- tz - lists.iana.org

British Summer Time end error
by Saras Sing Oct. 1, 2025

Oct. 1, 2025

Hello The United Kingdom British Summer Time ends at every last Sunday of November Thank you

7 6

[PROPOSED] Restore SUPPRESS_TZDIR support if OPENAT_TZDIR
by Paul Eggert Sept. 30, 2025

Sept. 30, 2025

The 09-28 changes inadvertently removed some support for the rarely-used SUPPRESS_TZDIR option. * localtime.c (tzloadbody) [OPENAT_TZDIR && SUPPRESS_TZDIR]: Do not open TZDIR, as when SUPPRESS_TZDIR we want relative pathnames to be relative to the working directory, not to TZDIR. --- localtime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/localtime.c b/localtime.c index 3937e5dd..186c7bf3 100644 --- a/localtime.c +++ b/localtime.c @@ -667,7 +667,7 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, return ENOTCAPABLE; } - if (OPENAT_TZDIR) { + if (OPENAT_TZDIR && !SUPPRESS_TZDIR) { /* Prefer O_SEARCH or O_PATH if available; O_RDONLY should be OK too, as TZDIR is invariably readable. O_DIRECTORY should be redundant but might help -- 2.48.1

1 0

Use -00 only for invalid time zones
by Dag-Erling Smørgrav Sept. 30, 2025

Sept. 30, 2025

Hi, I've had complaints from FreeBSD users and downstream vendors about the change in 2025a which replaced "UTC" with "-00" when we fail to load a time zone. It turns out quite a few people relied on the old default as a faster way of setting the time zone to UTC, and I can't say I blame them. The attached patch changes tzset_unlocked() slightly so that UNSPEC is only used if TZ was set or zoneinit() returned an error other than ENOENT, so the behavior TZ is unset and TZDEFAULT does not exist is unchanged but we still get an error indication if TZ is set to something we don't understand, or TZDEFAULT exists but can't be read, or TZDEFAULT is readable but not a valid TZif file. DES -- Dag-Erling Smørgrav - des(a)des.no

8 20

Improving tzcode localtime.c security a la FreeBSD
by Paul Eggert Sept. 29, 2025

Sept. 29, 2025

The first difference between FreeBSD and tzcode localtime.c that I'd like to address is that FreeBSD is more cautious about handling outlandish TZ settings like "../foo". It seems to me that tzcode should largely mimic FreeBSD's extra caution. In the long run I'd like tzcode localtime.c to be byte-for-byte identical to FreeBSD localtime.c but it's better to do this one step at a time and this security caution is a good first step. I noticed some minor issues with the FreeBSD implementation of this extra checking, so I propose implementing it in a somewhat different way in tzcode. I'm attaching proposed patches to do that, and have installed them in the tzcode development repository on GitHub. Here are issues I noticed: * With an environment variable setting like TZ="/usr/share/zoneinfo/America/Los_Angeles", in a privileged program FreeBSD first opens the directory /usr/share/zoneinfo to get a directory file descriptor, and then uses fstatat and openat, both with AT_RESOLVE_BENEATH. However, it passes the full name to fstatat which must be a typo; I can't see how that would work reliably for a setuid program, even though the neighboring code suggests it was intended to work. I assume it was intended to pass a relative name to fstatat. * As near as I can make out, in privileged programs FreeBSD rejects adjacent slashes in settings like TZ="/usr/share/zoneinfo//America/Los_Angeles", where there are two slashes after "zoneinfo". It would be nicer to treat those two slashes as if they were one, as the kernel does. * tzcode is intended to be portable to platforms lacking openat and AT_RESOLVE_BENEATH, so for now the attached patches mimic FreeBSD's extra checking without using these two features. There are efficiency motivations for using the two features if available, but I'd like to defer that to a later patchset. * Although FreeBSD takes some steps to treat TZ settings the same regardless of whether they come from the TZ environment variable, it doesn't take this idea to its logical conclusion. It seems to me that it's better to not care where the TZ setting came from, as that's easier to document, understand, and maintain, so the attached patches do that. * FreeBSD uses issetugid, which is not universally available. The attached patches work around this by supplying an issetugid substitute for platforms like GNU/Linux that lack it. The first attached patch is a minor indenting fixup. The second one is a minor efficiency improvement, to use strnlen instead of strlen when that improves asymptotic efficiency. The third patch adopts FreeBSD's idea of treating a TZ setting starting with "/usr/share/zoneinfo/" as if it lacked that prefix. And the fourth and main patch changes the tzcode security checks as described above. These tzcode patches do not address other differences between tzcode and FreeBSD, such as the multithreading differences or the check-for-changes differences. These can wait for later patchsets. Comments and suggestions are welcome as usual.

3 12

[PROPOSED] Also treat space as bogus in abbreviations
by Paul Eggert Sept. 29, 2025

Sept. 29, 2025

* NEWS: Mention this. * localtime.c (scrub_abbrs): Treat ' ' as bogus. --- NEWS | 5 +++++ localtime.c | 1 - 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 0436c615..2c354038 100644 --- a/NEWS +++ b/NEWS @@ -51,6 +51,11 @@ Unreleased, experimental changes -DHAVE_GETRESUID=[01], and -DHAVE_GETEUID=[01] to enable or disable these system calls' use. + tzset etc. now treat ' ' like '_' in time zone abbreviations, + just as they treat other invalid bytes. This continues the + transition begun in release 96k, which removed spaces in tzdata + because the spaces break time string parsers. + tzcode now uses mempcpy if available, guessing its availability. Compile with -DHAVE_MEMPCPY=1 or 0 to override the guess. diff --git a/localtime.c b/localtime.c index c5bc4e93..aa9ad7bd 100644 --- a/localtime.c +++ b/localtime.c @@ -504,7 +504,6 @@ scrub_abbrs(struct state *sp) for (i = 0; i < sp->charcnt; ++i) switch (sp->chars[i]) { case '\0': - case ' ': case '+': case '-': case '.': case '0': case '1': case '2': case '3': case '4': case '5': case '6': case '7': case '8': case '9': -- 2.48.1

1 0

[PATCH 1/3] Prefer mempcpy to doing it by hand
by Paul Eggert Sept. 29, 2025

Sept. 29, 2025

This is less error-prone. Supply a mempcpy if the system lacks it. * Makefile, NEWS: Mention this. * localtime.c (tzloadbody, tzparse): * zic.c (random_dirent, relname, doabbr): * zdump.c (my_snprintf) [!HAVE_SNPRINTF]: (istrftime): Prefer mempcpy to doing it by hand. * private.h (HAVE_MEMPCPY): New macro. (mempcpy) [!HAVE_MEMPCPY]: New function. --- Makefile | 1 + NEWS | 3 +++ localtime.c | 13 +++++++------ private.h | 17 +++++++++++++++++ zdump.c | 11 +++++++---- zic.c | 36 ++++++++++++++++++++---------------- 6 files changed, 55 insertions(+), 26 deletions(-) diff --git a/Makefile b/Makefile index 83122ecc..5b577781 100644 --- a/Makefile +++ b/Makefile @@ -262,6 +262,7 @@ LDLIBS= # -DHAVE_LOCALTIME_RZ=0 if you do not want zdump to use localtime_rz # localtime_rz can make zdump significantly faster, but is nonstandard. # -DHAVE_MALLOC_ERRNO=0 if malloc etc. do not set errno on failure. +# -DHAVE_MEMPCPY=1 if your system has mempcpy, 0 if not (default is guessed) # -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 diff --git a/NEWS b/NEWS index 5c4786cb..0436c615 100644 --- a/NEWS +++ b/NEWS @@ -51,6 +51,9 @@ Unreleased, experimental changes -DHAVE_GETRESUID=[01], and -DHAVE_GETEUID=[01] to enable or disable these system calls' use. + tzcode now uses mempcpy if available, guessing its availability. + Compile with -DHAVE_MEMPCPY=1 or 0 to override the guess. + tzcode now uses strnlen to improve asymptotic performance a bit. Compile with -DHAVE_STRNLEN=0 if your platform lacks it. diff --git a/localtime.c b/localtime.c index 67500312..316c7504 100644 --- a/localtime.c +++ b/localtime.c @@ -624,6 +624,7 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, } if (!SUPPRESS_TZDIR && name[0] != '/') { + char *cp; if (sizeof lsp->fullname - sizeof tzdirslash <= strnlen(name, sizeof lsp->fullname - sizeof tzdirslash)) return ENAMETOOLONG; @@ -631,8 +632,9 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, /* Create a string "TZDIR/NAME". Using sprintf here would pull in stdio (and would fail if the resulting string length exceeded INT_MAX!). */ - memcpy(lsp->fullname, tzdirslash, sizeof tzdirslash); - strcpy(lsp->fullname + sizeof tzdirslash, name); + cp = lsp->fullname; + cp = mempcpy(cp, tzdirslash, sizeof tzdirslash); + strcpy(cp, name); name = lsp->fullname; } @@ -1471,12 +1473,11 @@ tzparse(const char *name, struct state *sp, struct state const *basep) } sp->charcnt = charcnt; cp = sp->chars; - memcpy(cp, stdname, stdlen); - cp += stdlen; + cp = mempcpy(cp, stdname, stdlen); *cp++ = '\0'; if (dstlen != 0) { - memcpy(cp, dstname, dstlen); - *(cp + dstlen) = '\0'; + cp = mempcpy(cp, dstname, dstlen); + *cp = '\0'; } return true; } diff --git a/private.h b/private.h index 6ae0c2fd..867340fa 100644 --- a/private.h +++ b/private.h @@ -837,6 +837,23 @@ extern char *asctime_r(struct tm const *restrict, char *restrict); extern char **environ; #endif +#ifndef HAVE_MEMPCPY +# if (defined mempcpy \ + || defined __FreeBSD__ || defined __NetBSD__ || defined __linux__) +# define HAVE_MEMPCPY 1 +# else +# define HAVE_MEMPCPY 0 +# endif +#endif +#if !HAVE_MEMPCPY +static void * +mempcpy(char *restrict s1, char const *restrict s2, size_t n) +{ + char *p = memcpy(s1, s2, n); + return p + n; +} +#endif + #if 2 <= HAVE_TZNAME + (TZ_TIME_T || !HAVE_POSIX_DECLS) extern char *tzname[]; #endif diff --git a/zdump.c b/zdump.c index 8e836e60..93fe05cb 100644 --- a/zdump.c +++ b/zdump.c @@ -927,6 +927,7 @@ my_snprintf(char *s, size_t size, char const *format, ...) int n; va_list args; char const *arg; + char *cp; size_t arglen, slen; char buf[1024]; va_start(args, format); @@ -943,8 +944,9 @@ my_snprintf(char *s, size_t size, char const *format, ...) arglen = n; } slen = arglen < size ? arglen : size - 1; - memcpy(s, arg, slen); - s[slen] = '\0'; + cp = s; + cp = mempcpy(cp, arg, slen); + *cp = '\0'; n = arglen <= INT_MAX ? arglen : -1; va_end(args); return n; @@ -1073,8 +1075,9 @@ istrftime(char *buf, ptrdiff_t size, char const *time_fmt, char fbuf[100]; bool oversized = sizeof fbuf <= f_prefix_copy_size; char *f_prefix_copy = oversized ? xmalloc(f_prefix_copy_size) : fbuf; - memcpy(f_prefix_copy, f, f_prefix_len); - strcpy(f_prefix_copy + f_prefix_len, "X"); + char *cp = f_prefix_copy; + cp = mempcpy(cp, f, f_prefix_len); + strcpy(cp, "X"); formatted_len = strftime(b, s, f_prefix_copy, tm); if (oversized) free(f_prefix_copy); diff --git a/zic.c b/zic.c index 6bdb039d..e78dfd47 100644 --- a/zic.c +++ b/zic.c @@ -1327,10 +1327,10 @@ random_dirent(char const **name, char **namealloc) uint_fast64_t unfair_min = - ((UINTMAX_MAX % base__6 + 1) % base__6); if (!dst) { - dst = xmalloc(size_sum(dirlen, prefixlen + suffixlen + 1)); - memcpy(dst, src, dirlen); - memcpy(dst + dirlen, prefix, prefixlen); - dst[dirlen + prefixlen + suffixlen] = '\0'; + char *cp = dst = xmalloc(size_sum(dirlen, prefixlen + suffixlen + 1)); + cp = mempcpy(cp, src, dirlen); + cp = mempcpy(cp, prefix, prefixlen); + cp[suffixlen] = '\0'; *name = *namealloc = dst; } @@ -1430,15 +1430,17 @@ relname(char const *target, char const *linkname) if (*linkname == '/') { /* Make F absolute too. */ size_t len = strlen(directory); - size_t lenslash = len + (len && directory[len - 1] != '/'); + bool needs_slash = len && directory[len - 1] != '/'; + size_t lenslash = len + needs_slash; size_t targetsize = strlen(target) + 1; + char *cp; if (*directory != '/') return NULL; linksize = size_sum(lenslash, targetsize); - f = result = xmalloc(linksize); - memcpy(result, directory, len); - result[len] = '/'; - memcpy(result + lenslash, target, targetsize); + f = cp = result = xmalloc(linksize); + cp = mempcpy(cp, directory, len); + *cp = '/'; + memcpy(cp + needs_slash, target, targetsize); } for (i = 0; f[i] && f[i] == linkname[i]; i++) if (f[i] == '/') @@ -1448,11 +1450,13 @@ relname(char const *target, char const *linkname) taillen = strlen(f + dir_len); dotdotetcsize = size_sum(size_product(dotdots, 3), taillen + 1); if (dotdotetcsize <= linksize) { + char *cp; if (!result) result = xmalloc(dotdotetcsize); + cp = result; for (i = 0; i < dotdots; i++) - memcpy(result + 3 * i, "../", 3); - memmove(result + 3 * dotdots, f + dir_len, taillen + 1); + cp = mempcpy(cp, "../", 3); + memmove(cp, f + dir_len, taillen + 1); } return result; } @@ -2875,11 +2879,11 @@ doabbr(char *abbr, struct zone const *zp, char const *letters, else if (letters == disable_percent_s) return 0; sprintf(abbr, format, letters); - } else if (isdst) { - strcpy(abbr, slashp + 1); - } else { - memcpy(abbr, format, slashp - format); - abbr[slashp - format] = '\0'; + } else if (isdst) + strcpy(abbr, slashp + 1); + else { + char *abbrend = mempcpy(abbr, format, slashp - format); + *abbrend = '\0'; } len = strlen(abbr); if (!doquotes) -- 2.48.1

1 2

Changes to moderation procedures
by James Mitchell Sept. 29, 2025

Sept. 29, 2025

Hi all, We've made a small update to moderation settings in response to recent spam: * First posts from new members will be held for review. Once approved, the moderation flag will be removed. * All posts from non-members will continue to be held for moderation. A few existing members currently have moderation enabled. You may experience brief delays while these changes take effect—thank you for your patience. If you believe your messages are being held in error, please contact the list owners at tz-owner(a)iana.org<mailto:tz-owner@iana.org>. Kind regards, James Mitchell IANA

1 0

List moderation
by Kim Davies Sept. 24, 2025

Sept. 24, 2025

Hi folks, Our team have removed the list subscriber that flooded the list with emails in the last few minutes, and have put some emergency moderation in place until we can confirm it has died down. Apologies for the noise. kim

1 0

Prevent spam
by stan＠ulbrych.org Sept. 24, 2025

Sept. 24, 2025

Hello, I just received a barrage of emails (over 50) due to spam messages, I suggest the list owners look into first posts requiring approval before they are published. This is done for example in the Python docs list, and allows for such spam to be prevented. Best Regards, Stan Ulbrych

1 0

List moderation
by Kim Davies Sept. 24, 2025

Sept. 24, 2025

Hi folks, Our team have removed the list subscriber that flooded the list with emails in the last few minutes, and have put some emergency moderation in place until we can confirm it has died down. Apologies for the noise. kim

1 0

CRA auditor in BC checked commute route and distance in Toronto at rush hour BC time
by Brian Inglis Sept. 7, 2025

Sept. 7, 2025

How Google Maps helped one Toronto commuter beat traffic - and the tax collector: https://www.cbc.ca/news/canada/british-columbia/traffic-relocation-tax-cour… CRA auditor in BC checked commute route distance in Toronto at rush hour BC time! -- 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

1 0

TZLOAD_FROMENV flag used incorrectly
by Dag-Erling Smørgrav Aug. 31, 2025

Aug. 31, 2025

tzset_unlocked() calls zoneinit() with TZLOAD_STRINGS | TZLOAD_FROMENV regardless of whether name actually came from the environment. If name is null, zoneinit() will use TZDEFAULT instead, but will incorrectly consider that to be tainted, and unnecessarily perform an access check before trying to open it. That is luckily harmless in unmodified tzcode, but I would still prefer if TZLOAD_FROMENV were only set when actually true; see attached patch. DES -- Dag-Erling Smørgrav - des(a)des.no

2 3

[PROPOSED] Update tz-link for FTP, Go, Levine proposal
by Paul Eggert Aug. 31, 2025

Aug. 31, 2025

* tz-link.html: Remove links to projects that seem to be dead: MINIX, tziCal, tzdist-bis, Australian Parliamentary Library pub. Remove ftp: links as modern browsers don’t support them; instead, just mention FTP (and rsync, while we’re at it). Go seems to have fixed its 32-bit time_t bug. Cite British Sleep Society position paper on DST, and move the medical citations to a new list. Update citation to Judah Levine’s proposal to use 13-second leap smears every decade, as a substitute for leap seconds. --- tz-link.html | 115 +++++++++++++++++++++++++++------------------------ 1 file changed, 60 insertions(+), 55 deletions(-) diff --git a/tz-link.html b/tz-link.html index 76566224..669a3cb8 100644 --- a/tz-link.html +++ b/tz-link.html @@ -84,7 +84,6 @@ title="Berkeley Software Distribution">BSD</abbr></a>, <a href="https://www.chromium.org/chromium-os/">ChromiumOS</a>, <a href="https://cygwin.com">Cygwin</a>, <a href="https://mariadb.org">MariaDB</a>, -<a href="https://en.wikipedia.org/wiki/MINIX">MINIX</a>, <a href="https://musl.libc.org">musl libc</a>, <a href="https://www.mysql.com">MySQL</a>, <a href="https://en.wikipedia.org/wiki/WebOS"><abbr @@ -175,12 +174,15 @@ ustar interchange format</a>, compressed as described above; older releases use a nearly compatible format. Since version 2016h, each release has contained a text file named “<code>version</code>” whose first (and currently only) line is the version. -Older releases are <a href="https://ftp.iana.org/tz/releases/">archived</a>, -and are also available in an -<a href="ftp://ftp.iana.org/tz/releases/"><abbr -title="File Transfer Protocol">FTP</abbr> directory</a> via a -less secure protocol.</p> -<p>Alternatively, a development repository of code and data can be +<a href="https://ftp.iana.org/tz/releases/">Older archived releases are +available</a> via +<a href="https://en.wikipedia.org/wiki/HTTPS"><abbr +title="Hypertext Transfer Protocol Secure">HTTPS</abbr></a>, +<a href="https://en.wikipedia.org/wiki/Rsync"><abbr +title="remote sync">rsync</abbr></a>, and +<a href="https://en.wikipedia.org/wiki/FTP"><abbr +title="File Transfer Protocol">FTP</abbr></a>. +<p>Alternatively, a development repository of code and data can bem retrieved from <a href="https://github.com">GitHub</a> via the shell command:</p> <pre><code><a href="https://git-scm.com">git</a> clone <a href="https://github.com/eggert/tz">https://github.com/eggert/tz</a> @@ -195,7 +197,7 @@ After obtaining the code and data files, see the The code lets you compile the <code><abbr>tz</abbr></code> source files into machine-readable binary files, one for each location. The binary files are in a special format specified by -<a href="https://www.rfc-editor.org/rfc/9636">The +<a href="https://www.rfc-editor.org/rfc/rfc9636">The Time Zone Information Format (<abbr>TZif</abbr>)</a> (Internet <abbr title="Request For Comments">RFC</abbr> 9636). The code also lets @@ -249,7 +251,7 @@ with lines terminated by <a href="https://en.wikipedia.org/wiki/Newline"><abbr title="linefeed">LF</abbr></a>, which can be modified by common text editors such as <a href="https://www.gnu.org/software/emacs/">GNU Emacs</a>, -<a href="https://gedit-technology.github.io/apps/gedit/">gedit</a>, and +<a href="https://gedit-text-editor.org">gedit</a>, and <a href="https://www.vim.org">vim</a>. Specialized source-file editing can be done via the <a href="https://packagecontrol.io/packages/zoneinfo">Sublime @@ -377,21 +379,16 @@ calculates the current time difference between locations.</li> <section> <h2 id="protocols">Network protocols for <code><abbr>tz</abbr></code> data</h2> <ul> -<li>The <a href="https://www.ietf.org">Internet Engineering Task Force</a>’s -<a href="https://datatracker.ietf.org/wg/tzdist/charter/">Time Zone Data -Distribution Service (tzdist) working group</a> defined <a -href="https://www.rfc-editor.org/rfc/rfc7808">TZDIST</a> -(Internet <abbr>RFC</abbr> 7808), a time zone data distribution service, -along with <a href="https://www.rfc-editor.org/rfc/rfc7809">CalDAV</a> +<li><a href="https://www.rfc-editor.org/rfc/rfc7808">Time Zone +Data Distribution Service</a> (TZDIST, Internet <abbr>RFC</abbr> 7808) +is associated with +<a href="https://www.rfc-editor.org/rfc/rfc7809">CalDAV</a> (Internet <abbr>RFC</abbr> 7809), a calendar access protocol for transferring time zone data by reference. <a href="https://devguide.calconnect.org/Time-Zones/TZDS/">TZDIST -implementations</a> are available. -The <a href="https://www.ietf.org/mailman/listinfo/tzdist-bis">tzdist-bis -mailing list</a> discusses possible extensions.</li> -<li>The <a href="https://www.rfc-editor.org/rfc/rfc5545"> -Internet Calendaring and Scheduling Core Object Specification -(iCalendar)</a> (Internet <abbr>RFC</abbr> 5445) +implementations</a> are available.</li> +<li>The <a href="https://www.rfc-editor.org/rfc/rfc5545">iCalendar format</a> +(Internet <abbr>RFC</abbr> 5445) covers time zone data; see its VTIMEZONE calendar component. The iCalendar format requires specialized parsers and generators; a @@ -423,10 +420,6 @@ available under the <a href="https://www.gnu.org/copyleft/gpl.html"><abbr>GNU</abbr> General Public License (<abbr title="General Public License">GPL</abbr>)</a>.</li> -<li><a href="https://sourceforge.net/projects/tzical/">tziCal – tz -database conversion utility</a> is like Vzic, except for the <a -href="https://dotnet.microsoft.com">.NET framework</a> -and with a <abbr>BSD</abbr>-style license.</li> <li><a href="https://metacpan.org/release/DateTime-TimeZone">DateTime::TimeZone</a> contains a script <code>parse_olson</code> that compiles @@ -616,6 +609,9 @@ the Apache License.</li> library that translates between <abbr>UT</abbr> and civil time and can read <abbr>TZif</abbr> files. It is freely available under the Apache License.</li> +<li>The <a href="https://golang.org">Go programming language</a> +has a <abbr>TZif</abbr> file reader <a +href="https://pkg.go.dev/time#LoadLocationFromTZData"><code>LoadLocationFromTZData</code></a>.</li> <li>The <a href="https://github.com/nayarsystems/posix_tz_db"><code>posix_tz_db</code> package</a> contains Python code @@ -678,10 +674,6 @@ href="https://www.mozilla.org/en-US/thunderbird/">Thunderbird</a>. It displays multiple clocks in the application window, and has a mapping interface to <a href="https://www.google.com/earth/">Google Earth</a>. It is freely available under the <abbr>GPL</abbr>.</li> -<li><a href="https://golang.org">Go programming language</a> -implementations contain a copy of a 32-bit subset of a recent -<code><abbr>tz</abbr></code> database in a -Go-specific format.</li> <li>Microsoft Windows 8.1 and later has <code><abbr>tz</abbr></code> data and <abbr>CLDR</abbr> data (mentioned <a href="#CLDR">below</a>) used by the @@ -836,7 +828,8 @@ Saving Time – History, rationale, laws & dates</a> and summarized in History of Daylight Saving Time</a>.</li> <li><a href="https://www.laphamsquarterly.org/roundtable/time-lords">Time Lords</a> discusses how authoritarians manipulate civil time.</li> -<li><a href="https://www.w3.org/TR/timezone/">Working with Time Zones</a> +<li><a href="https://www.w3.org/TR/timezone/">Working with Time +and Time Zones</a> contains guidelines and best practices for software applications that deal with civil time.</li> <li><a href="https://webspace.science.uu.nl/~gent0113/idl/idl.htm">A History of @@ -851,10 +844,7 @@ Zone Concepts</a> discusses terminological issues behind time zones.</li> <h2 id="national">National histories of legal time</h2> <dl> <dt>Australia</dt> -<dd>The Parliamentary Library commissioned a <a -href="https://parlinfo.aph.gov.au/parlInfo/download/library/prspub/359V6/upload_b…">research -paper on daylight saving time in Australia</a>. -The Bureau of Meteorology publishes a list of <a +<dd>The Bureau of Meteorology publishes a list of <a href="http://www.bom.gov.au/climate/averages/tables/dst_times.shtml">Implementation Dates of Daylight Savings Time within Australia</a>.</dd> <dt>Belgium</dt> @@ -915,8 +905,8 @@ covers the history of local time in the Netherlands from ancient times.</dd> href="https://www.dia.govt.nz/Daylight-Saving-History">History of Daylight Saving</a>.</dd> <dt>Palestine</dt> -<dd>The Ministry of Telecom and IT publishes a <a -href="https://mtit.pna.ps/home/TimeZone" +<dd>The Ministry of Telecom and Digital Economy publishes a <a +href="https://mtde.gov.ps/home/TimeZone" hreflang="ar">history of clock changes (in Arabic)</a>.</dd> <dt>Portugal</dt> <dd>The Lisbon Astronomical Observatory publishes a @@ -957,9 +947,6 @@ zone shifts, and many scientific studies have been conducted. This section summarizes reviews and position statements based on scientific literature in the area.</p> <ul> -<li>In 2022 the American Medical Association issued a -<a href="https://www.ama-assn.org/press-center/press-releases/ama-calls-permanent-st…">statement -supporting permanent standard time</a> on health grounds.</li> <li>Carey RN, Sarma KM. <a href="https://bmjopen.bmj.com/content/7/6/e014319.long">Impact of daylight saving time on road traffic collision risk: a systematic @@ -969,22 +956,12 @@ This reviews research literature and concludes that the evidence neither supports nor refutes road safety benefits from shifts in time zones.</li> <li>Havranek T, Herman D, Irsova D. -<a href="https://www.iaee.org/en/publications/ejarticle.aspx?id=3051">Does -daylight saving save electricity? A meta-analysis</a>. +Does daylight saving save electricity? A meta-analysis. <em>Energy J.</em> 2018;39(2):35–61. doi:<a href="https://doi.org/10.5547/01956574.39.2.thav">10.5547/01956574.39.2.thav</a>. This analyzes research literature and concludes, “Electricity savings are larger for countries farther away from the equator, while subtropical regions consume more electricity because of <abbr>DST</abbr>.”</li> -<li>Malow BA. <a -href="https://academic.oup.com/sleep/article/45/12/zsac236/6717940">It is time -to abolish the clock change and adopt permanent -standard time in the United States: -a Sleep Research Society position statement</a>. -<em>Sleep.</em> 2022;45(12):zsac236. -doi:<a href="https://doi.org/10.1093/sleep/zsac236">10.1093/sleep/zsac236</a>. -After reviewing the scientific literature, the Sleep Research Society -advocates permanent standard time due to its health benefits. <li>Neumann P, von Blanckenburg K. <a href="https://journals.sagepub.com/doi/full/10.1177/0961463X241310562">What time will it be? A comprehensive literature review on daylight saving time</a>. @@ -993,6 +970,30 @@ doi:<a href="https://doi.org/10.1177/0961463X241310562">10.1177/0961463X24131056 This reviews DST’s effects on electricity, health, crime, road safety, and the economy, focusing on research since 2010, and concludes that year-round standard time is preferable overall. +</ul> + +<p>The following medical societies have taken positions on the +advisability of clock shifts:</p> + +<ul> +<li>In 2022 the American Medical Association issued a +<a href="https://www.ama-assn.org/press-center/press-releases/ama-calls-permanent-st…">statement +supporting permanent standard time</a> on health grounds.</li> +<li>Crawford MR, Winnebeck EC, von Schantz M <em>et al</em>. +<a href="https://onlinelibrary.wiley.com/doi/10.1111/jsr.14352">The +British Sleep Society position statement on Daylight Saving Time in the UK</a>. +<em>J Sleep Res.</em> 2025;34(3):e14352. +doi:<a href="https://doi.org/10.1111/jsr.14352">10.1111/jsr.14352</a>. +This recommends that the UK abolish DST for health reasons.</li> +<li>Malow BA. <a +href="https://academic.oup.com/sleep/article/45/12/zsac236/6717940">It is time +to abolish the clock change and adopt permanent +standard time in the United States: +a Sleep Research Society position statement</a>. +<em>Sleep.</em> 2022;45(12):zsac236. +doi:<a href="https://doi.org/10.1093/sleep/zsac236">10.1093/sleep/zsac236</a>. +After reviewing the scientific literature, the Sleep Research Society +advocates permanent standard time due to its health benefits.</li> <li>Rishi MA, Cheng JY, Strang AR <em>et al</em>. <a href="https://jcsm.aasm.org/doi/10.5664/jcsm.10898">Permanent standard time is the optimal choice for health and safety: @@ -1144,12 +1145,16 @@ to discontinue the use of leap seconds by 2035, and requested that no discontinuous adjustments be made to UTC for at least a century. The World Radiocommunication Conference <a href="https://www.itu.int/dms_pub/itu-r/opb/act/R-ACT-WRC.15-2023-PDF-E.pdf">resolved -in 2023</a> to cooperate with this process. -<a href="https://www.preprints.org/manuscript/202406.0043/v1">A proposal -to change the leap-second adjustments to Coordinated Universal Time</a> -(doi:<a href="https://doi.org/10.1088/1681-7575/ad6266">10.1088/1681-7575/ad6266</a>) -would replace leap seconds with 13-second leap smears occurring once per +in 2023</a> to cooperate with this process. One proposal to implement this +would replace leap seconds with seven 13-second leap smears occurring once per decade until 2100, with leap smears after that gradually increasing in size. +See: +<ul> +<li>Levine J. <a href="https://www.preprints.org/manuscript/202406.0043/v1">A +proposal to change the leap-second adjustments to +coordinated universal time</a>. <em>Metrologia.</em> 2024;61(5):055002. doi:<a +href="https://doi.org/10.1088/1681-7575/ad6266">10.1088/1681-7575/ad6266</a>.</li> +</ul> However, there is still no consensus on whether this is the best way to replace leap seconds. </li> -- 2.48.1

1 0

Using curved quotes etc. in TZDB HTML
by Paul Eggert Aug. 30, 2025

Aug. 30, 2025

After looking at today’s little change[1] to one of TZDB’s HTML files, I noticed that it cited Morrison et al’s 2020 paper but changed the paper’s title to use straight quotes 'like this' instead of curved quotes ‘like this’. Although TZDB’s HTML files mostly use straight quotes, they’re not methodical about it, and anyway straight quotes are to some extent a relic of the 20th century and in HTML files we can now reliably use curved quotes. So I composed a patch (attached) to be more consistent about quoting, and to use curved quotes except in places where the quotes are part of computer code and need to be straight. I haven’t installed this patch, though, because it’s annoying to edit HTML that looks like this: strings like “Prague”, “Praha”, “Прага”, and “布拉格”. I’d rather edit HTML that looks like this: strings like “Prague”, “Praha”, “Прага”, and “布拉格”. Since the HTML files are already UTF-8 encoded (otherwise they wouldn’t contain those non-ASCII letters) this shouldn’t be a problem with today’s editors. In 2014[2] I held off on making such a change because Garrett Wollman wrote that XEmacs 21.4 does not support quotes ‘like this’ or “like this”. However, XEmacs 21.4 has not been updated since 2009 and by now I would think XEmacs users would be using either XEmacs 21.5 (even though it’s still “beta”) or GNU Emacs, and both of these do support curved quotes. So instead of installing this patch, I’m inclined to install a different one in which HTML files use UTF-8 quotes “like this” rather than harder-to-read HTML entities “like this”. If this is OK we can also do something similar with other special characters such as “–” instead of “–”. Comments welcome. I am ccing this email to Garrett to see whether XEmacs 21.4 is still an issue with him. [1]: https://lists.iana.org/hyperkitty/list/tz@iana.org/message/BH63ZL5DHEBJPT2C… [2]: https://mm.icann.org/pipermail/tz/2014-June/046053.html

9 16

Re: Disabling adjustment, hyphenation, SGR, and page headers and footers in man pages
by Paul Eggert Aug. 28, 2025

Aug. 28, 2025

On 2025-08-27 16:42, G. Branden Robinson wrote: > I sent this to tz(a)iana.org a few days ago, but it appears to have gotten > discarded, maybe because I am not subscribed to the list. Yes, it's August and I suspect mailing list reviewers are on vacation. For tz list readers: Branden's original email is archived here: https://lists.gnu.org/r/groff/2025-08/msg00041.html > I have a suggestion for accomplishing all of the tasks named in the > Subject with command-line options to (recent) nroff. If I understand > the "workman.sh" script correctly, all that would be left for your > pipeline is to strip a trailing blank line. Thanks for the suggestion. As TZDB has been shipping *.txt files with single header and trailer lines for some time, I think we can simply prefer that style now for groff; this removes the need to strip a trailing blank line. For traditional nroff the best we can easily do is omit all headers and trailers, to avoid irritating headers elsewhere. > You might find it more convenient to use command-line options than to > append to macro definitions and otherwise inject *roff into nroff's > input stream (which is interpreted only after the macro package is > loaded, a fact that will have important consequences in groff 1.24). Thanks for the suggestion. Although this assumes groff we can do it just for groff (and for mandoc) and continue to do things the traditional way on old-fashioned (by now, very old-fashioned) hosts. I installed the attached proposed patches to implement your suggestion and a bit more.

1 0

Re: question regarding Mongolian timezone /Hovd GMT+/
by Munkh-Erdene Erdenebat Aug. 28, 2025

Aug. 28, 2025

Dear IANA Colleagues, I hope this message finds you well. My name is Munkh-Erdene from Mobicom Corporation, a mobile phone operator in Mongolia. I have a question regarding the Mongolian timezone, specifically for the Hovd region. According to various online sources, Mongolia currently has two time zones: Hovd (UTC+7) and Ulaanbaatar (UTC+8). The Hovd timezone is observed in three provinces: Hovd, Bayan-Ulgii, and Uvs. However, when I checked the tzdata files (zone.tab and zone1970.tab), it lists five provinces under the Hovd timezone. My understanding is that it should be only the three provinces mentioned above. Could you please advise on the process for requesting a correction in tzdata? Are there any specific requirements we need to meet? Also, please let me know if my understanding of the timezone coverage is incorrect. Thank you for your time and support. MUNKH-ERDENE Erdenebat Manager Core Network Department /CND/ CN&BSD/TS [mobicomnewlogo] Peace Avenue 3/1, Post Office-46 Ulaanbaatar-14201, Mongolia. Mobile : (976) 94081000 Web : www.mobicom.mn<http://www.newcom.mn/> From: Munkh-Erdene Erdenebat Sent: Wednesday, March 13, 2024 5:28 PM To: tz-owner(a)iana.org<mailto:tz-owner@iana.org> Subject: question regarding Mongolian timezone /Hovd GMT+/ Dear IANA Colleagues, How are you, doing well. I am Munkh-Erdene from Mobicom Corporation, which is Mongolian mobile phone operator. I've question regarding Mongolian timezone. We have some misunderstanding regarding Mongolian timezone, specially for Hovd region. As we checked from internet, it says there is 2 timezone in Mongolia now. Hovd+7 and Ulaanbaatar +8. Behind of Hovd region, there is 3 provinces which is Hovd, Bayan-Ulgii & Uvs. [cid:image004.png@01DC1810.84CC7F10][cid:image007.jpg@01DC1810.84CC7F10] World Time Zone Map (24timezones.com)<https://24timezones.com/timezone-map> Mongolia Time Zone - WhichTimezone<https://whichtimezone.com/asia/mongolia/> But when I checked from tzdata file. Zone.tab & zone1970.tab files. There is 5 aimags behind of Hovd region, it should be 3 provinces which is Hovd, Bayan-Ulgii & Uvs. We want to correct it on tzdata, how can we send request to you and is there any requirements from you? please correct me if I was checked wrongly. [cid:image008.jpg@01DC1810.84CC7F10] [cid:image009.jpg@01DC1810.84CC7F10] MUNKH-ERDENE Erdenebat Department Manager Network Operation & Maintenance Department /NOMD/ TOMD/TOMS [mobicomnewlogo] Peace Avenue 3/1, Post Office-46 Ulaanbaatar-14201, Mongolia. Mobile : (976) 94081000 Web : www.mobicom.mn<http://www.newcom.mn/> ???????? ?????? ????? ?????? ?? (????????????? ????) ?????? ?????? ?????????? ?????????, ?????? ???? ??? ????? ???????? ???????????? ?????. ?? ????? ??????? ??????????? ???????? ?? ??????? ?????????????, ????????? ???????? ?????? ?????? ??????????? ???????????? ???? ?????????? ? ??????? ????????????? ??? ?? ????????????? ??. ????? ?? ?? ????? ??????? ??????? ???????? ?????? ????? ??? ??? ?????? ????? ??????? ????????? ????? ????? ?????? ?????? ?????? ????????, ?????????? ????? ????? ????? ??????? ?????? ????????? ??? ????? ?????? ???? ??????? ???? ??. ???????? ?????? ???????? ??????????? ?????????? ?????? ????????? ?????????, ??????????, ?????? ?????? ????? ?? ??????????? ????????? ??????? ????? ?????? ????, ?? ?????? ????? ????? ??? ?????? ???????? ??. Disclaimer This email (including any attachments) is intended only to be read and used by the addressee. It may contain confidential or legally privileged information, which is not waived if it is mistakenly delivered to you. If you are not the intended recipient, please immediately notify the sender by return email and delete both messages from your system; any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.

3 3

Asia/Riyadh TZ abbreviation "+03"?
by Peter Chamberlin Aug. 25, 2025

Aug. 25, 2025

Wouldn’t this be better defined as "AST" for Arabia Standard Time per https://24timezones.com/Riyadh/time?

5 9

[PROPOSED 1/3] Fix adjustment and hyphenation in *.txt files
by Paul Eggert Aug. 24, 2025

Aug. 24, 2025

* date.1: Remove no-longer-needed .nh and .na. * workman.sh: Modernize the code that disables adjustment and hyphenation, to work in groff 1.23 too. Add comments. --- date.1 | 2 -- workman.sh | 18 +++++++++++++++--- 2 files changed, 15 insertions(+), 5 deletions(-) diff --git a/date.1 b/date.1 index 3a02e7c2..5f334358 100644 --- a/date.1 +++ b/date.1 @@ -4,8 +4,6 @@ .SH NAME date \- show and set date and time .SH SYNOPSIS -.if n .nh -.if n .na .B date [ .B \-u diff --git a/workman.sh b/workman.sh index 29f317cb..ad1a9532 100644 --- a/workman.sh +++ b/workman.sh @@ -9,12 +9,24 @@ if (type nroff && type perl) >/dev/null 2>&1; then # Tell groff not to emit SGR escape sequences (ANSI color escapes). export GROFF_NO_SGR=1 - echo ".am TH -.hy 0 + printf '%s\n' '. +.\" -- Tailor groff -man -- +. +.\" Left-adjust and do not hyphenate. +.ds AD l +.nr HY 0 +. +.\" -- Tailor traditional troff -man -- +. +.\" Left-adjust and do not hyphenate. +.am TH .na +.hy 0 .. +.\" Omit page headers and footers. .rm }H -.rm }F" | nroff -man - ${1+"$@"} | perl -ne ' +.rm }F +.' | nroff -man - ${1+"$@"} | perl -ne ' binmode STDIN, '\'':encoding(utf8)'\''; binmode STDOUT, '\'':encoding(utf8)'\''; chomp; -- 2.50.1

1 2

Possible upcoming change to America/Argentina/*, from -03 to -04
by Salvador Pardiñas Aug. 23, 2025

Aug. 23, 2025

Hi all! I wanted to warn you about a potential change to all the Argentinean timezones, as a law proposal looking to move the entire country to GMT-4 has now passed the Lower Chamber of Parliament, and is now waiting for approval by the Upper Chamber of Parliament: https://www.lanacion.com.ar/politica/la-camara-de-diputados-le-dio-media-sa… https://www.infobae.com/sociedad/2025/08/21/cambio-de-huso-horario-en-argen…

1 0

[PATCH] Mention Qinling Station opened in Antarctica on 2024-02-07.
by Collin Funk Aug. 16, 2025

Aug. 16, 2025

Hi Paul, Regarding this comment at the top of the antartica file: # From Paul Eggert (1999-11-15): # To keep things manageable, we list only locations occupied year-round; see # COMNAP - Stations and Bases # http://www.comnap.aq/comnap/comnap.nsf/P/Stations/ [...] You may want to update it to link to page which is not dead [1]. It contains a link to "COMNAP Antarctic Facilities List", which is a file that is updated periodically as things change in Antarctica (not often, I assume?). Currently it is this [2]. Anyways, China opened a new year-round base in 2024 that it is probably worth mentioning [3]. It has a higher population than their other ones, if Wikipedia is to be trusted [4]. Patch attached. Collin [1] https://www.comnap.aq/antarctic-facilities-information [2] https://www.comnap.aq/s/Facilities_Nov2024.csv [3] https://www.reuters.com/world/china/china-opens-antarctic-station-south-aus… [4] https://en.wikipedia.org/wiki/Qinling_Station

2 1

DST in Baja California 1973
by Alois Treindl Aug. 6, 2025

Aug. 6, 2025

TZ maintains for zone America/Tijuana that there was not DST observed between 1961 and 1975. > # Baja California > Zone America/Tijuana -7:48:04 - LMT 1922 Jan 1 7:00u > -7:00 - MST 1924 > -8:00 - PST 1927 Jun 10 > -7:00 - MST 1930 Nov 15 > -8:00 - PST 1931 Apr 1 > -8:00 1:00 PDT 1931 Sep 30 > -8:00 - PST 1942 Apr 24 > -8:00 1:00 PWT 1945 Aug 14 23:00u > -8:00 1:00 PPT 1945 Nov 15 # Peace > -8:00 - PST 1948 Apr 5 > -8:00 1:00 PDT 1949 Jan 14 > -8:00 - PST 1950 May 1 > -8:00 1:00 PDT 1950 Sep 24 > -8:00 - PST 1951 Apr 29 2:00 > -8:00 1:00 PDT 1951 Sep 30 2:00 > -8:00 - PST 1952 Apr 27 2:00 > -8:00 1:00 PDT 1952 Sep 28 2:00 > -8:00 - PST 1954 > -8:00 CA P%sT 1961 > -8:00 - PST 1976 > -8:00 US P%sT 1996 > -8:00 Mexico P%sT 2001 > -8:00 US P%sT 2002 Feb 20 > -8:00 Mexico P%sT 2010 > -8:00 US P%sT A user of our astrology service, born in 1973 in he border town Mexicali claimed that they observed DST in his town, just like on the other side of the border in California, when he was born on 30 May 1973. I did a quick newspaper archive research on https://hndm.iib.unam.mx/ and found that Título: Periódico Oficial del Estado de Baja California Norte Fecha: 1973-04-20 states clearly that DST was observed from last Sunday in April to last Sunday in October. This means the the TZ table above is false, at least for 1973. I assume that the same is the case for several other years. I attach the screenshot for 1973 The page https://hndm.iib.unam.mx/consulta/publicacion/visualizar/558075be7d1e63c9fe… should allow to search for other years as well. I used the keywords *hora legal* for my search, though do not see that now in the URL.

4 7

Fwd: Bulletin C number 70
by Tim Parenti Aug. 4, 2025

Aug. 4, 2025

No leap second 2025-12-31, per below. See attached patch. -- Tim Parenti ---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc(a)obspm.fr> Date: Mon, 7 Jul 2025 at 05:43 Subject: Bulletin C number 70 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, 07 July 2025 Bulletin C 70 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO leap second will be introduced at the end of December 2025. 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

4 11

Error in the Annuaire du Bureau des Longitudes for 1923
by Santoni Francis July 23, 2025

July 23, 2025

Hello, The most surprising thing, when I checked, in the 1980s, the consistency of this date of 1923 in the newspapers of the time, is that even in the daily newspapers there was, the day before, only a very short article, in the inside pages of the newspaper, whereas, in the same newspaper, for the previous years, the article indicating summer hours was always clearly visible. If I remember correctly, during the preceding months, the questioning about summer hours was reduced to procrastination. Le plus étonnant, lorsque j'ai vérifié, dans les années 80, la cohérence de cette date de 1923 dans les journaux de l'époque, c'est que même dans les quotidiens il n'y avait, la veille qu'un très court article, dans les pages intérieures du journal, alors que, dans le même journal, pour les années précédentes, l'article signalant les heures d'été était toujours bien visible. Si je me souviens bien, durant les mois précédents, le questionnement sur les heures d'été se résumait à des atermoiements. Francis Santoni

1 0

Yucatán thinks of moving from -06 to -05
by Paul Eggert July 23, 2025

July 23, 2025

Yucatán, which corresponds to TZDB’s America/Merida, is considering switching from -06 (CST) all year to -05 (EST) all year.[1] This would be akin to observing permanent daylight saving time. (Yucatán last observed DST in 2022, after which Mexico abolished DST except in regions near the US.) There does not seem to be any rush to decide whether to make the change. If Yucatán does switch presumably Campeche will not, so we would therefore need to split America/Merida into two zones, and as Mérida is in Yucatán we would need a new name for Campeche. The largest city in the Mexican state of Campeche is its capital San Francisco de Campeche, commonly called just “Campeche” like the state, so presumably America/Campeche would be the name of the new TZDB zone. One possible date and time for Yucatán’s hypothetical switch would be March 8, 2026 at 02:00, which is when US CST is planned to switch to CDT. Any such transition is purely speculative at this point, though, so I am not now proposing a patch to TZDB. [1]: David Domínguez Massa. Posturas desde el Congreso de Yucatán sobre homologar el horario con Quintana Roo. Diario de Yucatán. 2025-07-05. https://www.yucatan.com.mx/merida/2025/07/05/posturas-desde-el-congreso-de-…

1 0

Should all IDs from backzone be available in backward?
by robertbastian＠unicode.org July 2, 2025

July 2, 2025

The set of IDs (zones and links) in backzone is _almost_ a subset of the IDs in backward; the only ID that is in backzone but not in backward is Asia/Hanoi. Can Asia/Hanoi be added as a link in backward to ensure compatibility with systems that use IDs from backzone? Is this a desirable invariant that can be upheld in the future? This was reported to CLDR (https://unicode-org.atlassian.net/browse/CLDR-11977) so it looks like there are systems that are using these IDs.

6 8