- tz - lists.iana.org

Asia/Shanghai error?
by Komka Péter March 13, 2024

March 13, 2024

Hi, tzdata2024a contains (erroneously?): # Zone NAME STDOFF RULES FORMAT [UNTIL] # Beijing time, used throughout China; represented by Shanghai. #STDOFF 8:05:43.2 Zone Asia/Shanghai 8:05:43 - LMT 1901 8:00 Shang C%sT 1949 May 28 8:00 PRC C%sT <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< # Xinjiang time, used by many in western China; represented by Ürümqi / Ürümchi # / Wulumuqi. (Please use Asia/Shanghai if you prefer Beijing time.) Zone Asia/Urumqi 5:50:20 - LMT 1928 6:00 - +06 Shanghai refers to the rule "PRC". # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule PRC 1986 only - May 4 2:00 1:00 D Rule PRC 1986 1991 - Sep Sun>=11 2:00 0 S Rule PRC 1987 1991 - Apr Sun>=11 2:00 1:00 D Rule PRC was only in use until 1991. Currently, in 2024, there is no rule "PRC" in use. The local time Asia/Shanghai refers to a non-existing rule. Possibly: Asia/Shanghai time currently (2024) has NO DST-rule. Similarly to Asia/Urumqi. https://en.wikipedia.org/wiki/China says: "Time zone UTC+8 (CST) / DST is not observed." https://www.timeanddate.com/worldclock/china shows: there is [officially] only one time in China, "CST", "UTC +8". Even is Ürümqi. https://www.timeanddate.com/time/change/china (a sub-link from the previos link) "Daylight Saving Time (DST) Not Observed in Year 2024" "The previous DST change in China was on 15 September 1991." -- Komka Peter (please do not spam)

3 2

Re: [tz] Some issues regarding the tz database
by Paul Eggert March 11, 2024

March 11, 2024

On 2024-03-10 21:07, xzx_work_2020 wrote: > 1) About echo" IST-2IDT, M3.44/26, M10.5.0 ">/tmp/TZ": > I don't know why there is an extra space in the mail, but I actually use is no space. Oh, one other thing, it should be "M3.4.4" not "M3.44".

1 0

Re: [tz] Some issues regarding the tz database
by Paul Eggert March 10, 2024

March 10, 2024

On 2024-03-10 01:42, xzx_work_2020 wrote: > I used 'cat Asia/Jerusalem' and the result was "IST-2IDT, M3.44/26, M10.5.0". > However, when I used "echo" IST-2IDT, M3.44/26, M10.5.0 ">/tmp/TZ", this did not work. I would omit the extra spaces after the ","s. Also, don't you need to put it into /etc/TZ? That is, the command should be something like this: echo "IST-2IDT,M3.4.4/26,M10.5.0" >/etc/TZ if you're using OpenWRT with musl. > Question 1: Is it necessary to handle items that exceed 24 hours during use in this way? POSIX.1-2017 does not require support for the "/26". However, it is a common extension (it's in glibc for example), and the next POSIX release is planned to require support for times from -167:59:50 through +167:59:59. As I understand it, older versions of musl did not support "/26", but newer versions do. (I don't know when this feature was added to musl.) Perhaps all you need to do is upgrade musl versions. > Question 2: I saw from online sources that Asia/Jerusalem entered daylight saving time at 2:00 pm on Friday, March 29, 2024. However, the data in the database seems to be calculated to be 2:00 pm on Friday, the fourth week of March, which is also 2:00 pm on Friday, March 22, 2024. Did I misunderstand this? Or is there an error in the data in the database? I think you misunderstood it. The relevant line in the "asia" file is: Rule Zion 2013 max - Mar Fri>=23 2:00 1:00 D which says the transition is the first Friday on or after March 23, at 02:00. This matches current Israeli law, which says the transition occurs at 2 am on the Friday before March's last Sunday. This rule cannot be encoded in a POSIX.1-2017 TZ setting, which is partly why the next POSIX release will allow the "/26".

1 0

Weird PST8PDT and EST5EDT behavior on Alpine Linux
by Russ Allbery March 9, 2024

March 9, 2024

This probably belongs on an Alpine-specific mailing list, but this was odd enough that I'm wondering if I'm missing something about the interpretation of legacy POSIX time zone strings. There is probably some obvious answer that I will feel dumb for not spotting. $ cat /etc/alpine-release 3.19.0 $ apk list tzdata tzdata-2023d-r0 x86 {tzdata} (Public-Domain) [installed] $ apk info --who-owns /bin/date /bin/date symlink target is owned by busybox-1.36.1-r15 $ env TZ=PST8PDT date -R -d @1643145780 Tue, 25 Jan 2022 14:23:00 -0700 $ env TZ=EST5EDT date -R -d @1643145780 Tue, 25 Jan 2022 17:23:00 -0400 Why would the system decide that time stamp should use daylight saving time? The system time zone is set to UTC, so it shouldn't be some sort of contamination from it. Or is this some odd bug in the busybox date command? It works correctly with busybox 1.36.1 on a Debian system, though: % busybox env TZ=PST8PDT date -R -d @1643145780 Tue, 25 Jan 2022 13:23:00 -0800 The Alpine Linux system in question does have PST8PDT and EST5EDT files in /usr/share/zoneinfo. The Olson time zone identifiers do work as expected: $ env TZ=America/Los_Angeles date -R -d @1643145780 Tue, 25 Jan 2022 13:23:00 -0800 $ env TZ=America/New_York date -R -d @1643145780 Tue, 25 Jan 2022 16:23:00 -0500 (We ran into this because it caused test failures in tests of INN's date parsing library. I wrote those tests eons ago and they used PST8PDT as the time zone because when I wrote them there were still some INN users who were using systems that didn't use the Olson database.) -- Russ Allbery (eagle(a)eyrie.org) <https://www.eyrie.org/~eagle/>

6 18

A Partly-Baked Idea
by Bill Seymour March 8, 2024

March 8, 2024

Could there be a "Version 4" of the compiled TZif files in which the ints and time_ts have the correct endianness for the platform on which they're installed? I imagine a zic command-line argument that selects: - always big-endian (the default for compatibility), - always little-endian, or - the correct endianness for the platform on which zic is running. This wouldn't let users rip out all their endianness code since not all TZif files would be version 4; but it might reduce running time in programs that read lots of TZif files. Does this make sense, or is it just premature optimization? --Bill Seymour

7 7

posix and right directories?
by Bill Seymour March 5, 2024

March 5, 2024

Is there some document that explains what the posix and right subdirectories in my Linux' /usr/share/zoneinfo are all about? Are they a regular Zoneinfo thing, or are they somehow specific to Debian Linux? I checked theory.html and didn't see anything related to this. --Bill Seymour

3 2

Eastern Standard Tribe - Cory Doctorow
by Brian Inglis March 3, 2024

March 3, 2024

Suggest mentioning in tz-art.html: Cory Doctorow's 2004 novel "Eastern Standard Tribe" Quotes from blurbs: "He may live in London and work for an EU telecommunications megacorp, but Art's real home is the Eastern Standard Tribe. ... The world is slowly splintering into Tribes held together by a common time zone, less than family and more than nations." "The book concerns itself with the conspiracies of management consultants around the world who form secret allegiences on the basis of the timezones that they choose to sleep in - everyone who keeps New York time all over the world ends up all pallsy-wallsy and savages those degenerates on Pacific time." https://www.goodreads.com/book/show/7143989-eastern-standard-tribe https://en.wikipedia.org/wiki/Eastern_Standard_Tribe downloadable for free in many formats with his other books from https://craphound.com/est/download/ -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

2 1

Happy Leap Day...
by Arthur David Olson March 1, 2024

March 1, 2024

...to those who celebrate; Happy March 0 to those who don't. @dashdashado

4 3

NZ Leap Day Self Pay Petrol Pump Failures
by Brian Inglis March 1, 2024

March 1, 2024

https://arstechnica.com/gadgets/2024/02/leap-year-glitch-broke-self-pay-pum… -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

7 9

[PROPOSED] Asia/Almaty matches Asia/Tashkent from now on
by Paul Eggert March 1, 2024

March 1, 2024

This pacifies ‘make check_now’. * NEWS: Mention this. * zonenow.tab: Remove Asia/Almaty. --- NEWS | 9 +++++++++ zonenow.tab | 4 +--- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index 43f2ab05..8efa195f 100644 --- a/NEWS +++ b/NEWS @@ -1,5 +1,14 @@ News for the tz database +Unreleased, experimental changes + + Changes to data + + Asia/Almaty has been removed from zonenow.tab as it now agrees + with Asia/Tashkent for future timestamps, due to Kazakhstan's + 2024-02-29 time zone change. + + Release 2024a - 2024-02-01 09:28:56 -0800 Briefly: diff --git a/zonenow.tab b/zonenow.tab index b6f29109..1e7a86be 100644 --- a/zonenow.tab +++ b/zonenow.tab @@ -199,7 +199,7 @@ XX +2518+05518 Asia/Dubai Russia; Caucasus; Persian Gulf; Seychelles; Réunion XX +3431+06912 Asia/Kabul Afghanistan # # +05 -XX +4120+06918 Asia/Tashkent Russia; west Kazakhstan; Tajikistan; Turkmenistan; Uzbekistan; Maldives +XX +4120+06918 Asia/Tashkent Russia; Kazakhstan; Tajikistan; Turkmenistan; Uzbekistan; Maldives # # +05 - PKT XX +2452+06703 Asia/Karachi Pakistan ("PKT") @@ -215,8 +215,6 @@ XX +2743+08519 Asia/Kathmandu Nepal # # +06 XX +2343+09025 Asia/Dhaka Russia; Kyrgyzstan; Bhutan; Bangladesh; Chagos -# +06 until 2024-03-01; then +05 -XX +4315+07657 Asia/Almaty Kazakhstan (except western areas) # # +06:30 XX +1647+09610 Asia/Yangon Myanmar; Cocos -- 2.40.1

1 0

Administrivia: Mailing List Archives
by Kim Davies Feb. 25, 2024

Feb. 25, 2024

Hi all, We’ve done a little bit of work to fix some old corrupted email messages in the mailing list archive at http://mm.icann.org/pipermail/tz/. They’ve been corrupted ever since they were originally imported over a decade ago, but were noticed by an astute reader recently. Also, some of the historical links were broken for roughly the last three weeks for an unrelated reason, but these should work as expected now. If you notice anything awry please let me know. kim

2 1

leap-seconds.list format
by Byron Torres Feb. 19, 2024

Feb. 19, 2024

Good day, I write here to you knowledgeable people in the hopes you can clarify some things regarding the format of leap-seconds.list file. Please forgive me if there is a more appropriate place to ask. Recently it seems the IERS has changed the format of the leap-seconds.list file they serve[1], from the old format by NIST[2]. The comments are reworded, the lines wrap at a large width, and most importantly, the whitespace between the decimal timestamps and time-differences, previously a tab, have been replaced with spaces. [1] https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list [2] ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list This, coupled with the fact that the tz repository recently began fetching from this source (I understand that is because the NIST source was flaky), has broken a leap-seconds.list parser[3] used by the standard library of the Hare systems programming language[4], a language akin to a modern C. I'm the maintainer of the Hare stdlib date/time subsystem[5]. [3] https://git.sr.ht/~sircmpwn/hare/tree/d0c057dbbb0f1ee9179769e187c0fbd3b0032… [4] https://harelang.org/ [5] https://harelang.org/who For context, Hare sources leap-seconds.list for UTC-TAI leapsecond data and implements timescales like UTC, TAI, GPS, etc. Hare could source from a TZIF file specified by $TZ, but the decoupling of timezone and leapsecond data allows for multi-timescale programming. We are working to improve Hare and to begin stable quarterly releases, so we ideally want guarantees for how leap-seconds.list is formatted. My questions are: * What was the motivation for the changes in IERS'es leap-seconds.list file? Is there a record of discussion regarding this? * What was the motivation specifically for the spaces-to-tab change? Did another commonly used software implement a forgiving parser? * What is the history of the leap-seconds.list file and file format? * Is the format for leap-seconds.list defined? Where and how strongly? * If there is no strong, formal definition, would a formal definition of the leap-seconds.list file format be welcome? To whom could I coordinate with? * Could at least the spaces be changed back to tabs? Personally, I do not like the idea of a make-time conversion script. It would be ideal for the source file to make this change, but before I email the contact mentioned in the new file, I thought to prod here first. Timely regards, b

5 20

timezone-related error sparks $340 million lawsuit
by Paul Eggert Feb. 19, 2024

Feb. 19, 2024

In "US man sues Powerball lottery after being told his apparent $340m win was error"[1], Maya Yang reported in today's Guardian that a mistake caused by a quality-assurance team checking timezone configuration for a Powerball lottery website has snowballed into a $340 million lawsuit against the lottery. Due to the mistake, in which a test version of the website was loaded with random numbers, the lottery's production website temporarily displayed the wrong winning numbers. A man whose ticket matched those numbers is now suing the lottery for the $340 million prize, saying he is the rightful winner. Yang reported that the errant QA team was testing "a task involving a changing of time zones for the Powerball website from Coordinated Universal Time to Eastern Standard Time." [1]: https://www.theguardian.com/us-news/2024/feb/18/man-sues-powerball-lottery-…

1 0

Checked arithmetic bug
by Dag-Erling Smørgrav Feb. 17, 2024

Feb. 17, 2024

In at least one instance around line 1187 of localtime.c, the code assumes that increment_overflow_time() does not modify the result if the operation overflowed, but that is not true when using C23 checked arithmetic. Details: https://bugs.freebsd.org/276281, particularly comment 11. One possible solution is attached. I'm not overly fond of it because it penalizes the common case, but it was easier than trying to understand and reformulate the loop in tzparse(). DES -- Dag-Erling Smørgrav - des(a)des.no

2 1

the Republic of Kazakhstan
by ЕЛИКБАЕВ КУАНЫШ НУРЛАНОВИЧ Feb. 5, 2024

Feb. 5, 2024

Dear colleagues, Technical Regulation and Metrology Committee of the Ministry of Trade and Integration of the Republic of Kazakhstan (CTRM) takes this opportunity to express its assurances of the highest consideration. CTRM participates in the implementation of strategic functions of the Ministry in the areas of technical regulation and Metrology. CTRM informs that by the Decree of the Government of the Republic of Kazakhstan dated January 19, 2024 No. 20, amendments have been made to the Decree of the Government of the Republic of Kazakhstan dated November 23, 2000 No. 1749 «On the procedure for calculating time on the territory of the Republic of Kazakhstan» (https://zan.gov.kz/client/#!/doc/192700/rus) which provides, among other things, for the Akimats of the cities of Astana, Almaty, Shymkent, Akmola, Almaty, Zhambyl, Karaganda, Kostanay, Pavlodar, North Kazakhstan, Turkestan, East Kazakhstan regions and Abay, Zhetisu, Ulytau regions, on the night of February 29, 2024 to March 1, 2024 (Astana time, 12:00 a.m.), to transfer local time back 1 hour Information that the Republic of Kazakhstan is switching to Single Time Zone (UTC+05:00) is sent for accounting in work when interacting with government agencies and organizations of the Republic of Kazakhstan. Please find the attached letter. Sincerely, Mr. Kuanysh Yelikbayev Chairman

2 1

Kazakhstan to shift from UTC+6 to UTC+5
by Dauren Sarsenov Feb. 5, 2024

Feb. 5, 2024

Hello, all. There is an upcoming timezone change I want to inform you about. In Kazakhstan we are moving away from UTC+6 to UTC+5 across all areas of the country. The change is effective at 00:00 1 march 2024. The clock will shift 1 hour back. After the change, only the UTC+5 timezone will remain in the country. I have linked the official statement (no Eng version of the statement though) and some links to news articles: 1) KAZ: https://www.gov.kz/memleket/entities/mti/press/news/details/688998?lang=kk 2) RUS: https://www.gov.kz/memleket/entities/mti/press/news/details/688998?lang=ru 3) KAZ: http://law.gov.kz/client/#!/doc/192700/kaz 4) RUS: http://law.gov.kz/client/#!/doc/192700/rus 5) ENG: https://daryo.uz/en/2024/01/21/kazakhstan-set-to-shift-to-utc5-time-zone-on… 6) ENG: https://qazmonitor.com/news/2430/kazakhstan-to-change-the-clocks-to-single-… The news broke 19th of january, hence informing you at the short notice. Best regards Dauren Sarsenov

5 10

[PROPOSED] Update Israel tz-link
by Paul Eggert Feb. 4, 2024

Feb. 4, 2024

* tz-link.html (National histories of legal time): Update Israel tz history link. (Thanks to Ephraim Silverberg.) --- tz-link.html | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/tz-link.html b/tz-link.html index f11873d9..d41bbce6 100644 --- a/tz-link.html +++ b/tz-link.html @@ -897,9 +897,10 @@ summarizes and cites historical <abbr>DST</abbr> regulations.</dd> href="https://www.ptb.de/cms/en/fachabteilungen/abt4/fb-44/ag-441/realisation-of-…">Realisation of Legal Time in Germany</a>.</dd> <dt>Israel</dt> -<dd>The Interior Ministry periodically issues <a -href="ftp://ftp.cs.huji.ac.il/pub/tz/announcements" -hreflang="he">announcements (in Hebrew)</a>.</dd> +<dd><a +href="https://tz.cs.huji.ac.il/">Israel Timezone Files</a> +lists official time-change announcements and laws since 1940, +almost all in Hebrew.</dd> <dt>Malaysia</dt> <dd>See Singapore <a href="#Singapore">below</a>.</dd> <dt>Mexico</dt> -- 2.40.1

1 0

Extending winter time in Palestine
by heba.hamad Feb. 4, 2024

Feb. 4, 2024

3 3

RFC 8536bis
by Michael H Deckers Feb. 3, 2024

Feb. 3, 2024

In 2014b, the new tzdb timezone for Antarctica/Troll required regular switches among three offsets for the foreseeable future. This led to an extension of the TZif format so that the footer could contain two TZ strings (or so I thought); the timezone Antarctica/Troll, hwever, was modified so as to not yet require the new TZif feature. Now it appears that the latest specification "RFC 8536bis" of the TZif format does not allow for two TZ strings in the footer (or at least I did not detect it). Does that mean that the feature "two TZ strings" in a TZif file is further postponed, or is it dropped for good? Michael Deckers.

3 9

[PROPOSED 1/2] Streamline tz-link a bit
by Paul Eggert Feb. 1, 2024

Feb. 1, 2024

* tz-link.html: Defer to the Timezone Boundary Builder web page for a list of libraries that use it, as its list is larger and better-maintained than ours. Mention how old the Manifold map is. Mention WRC 2023 resolution on leap seconds. --- tz-link.html | 36 ++++++++---------------------------- 1 file changed, 8 insertions(+), 28 deletions(-) diff --git a/tz-link.html b/tz-link.html index 78c266ee..9fb57c90 100644 --- a/tz-link.html +++ b/tz-link.html @@ -787,32 +787,9 @@ boundaries of <code><abbr>tzdb</abbr></code> timezones. Its code is freely available under the <abbr>MIT</abbr> license, and its data entries are freely available under the <a href="https://opendatacommons.org/licenses/odbl/">Open Data Commons -Open Database License</a>. The maps' borders appear to be quite accurate.</li> -<li>Programmatic interfaces that map geographical coordinates via tz_world to -<code><abbr>tzdb</abbr></code> timezones include: -<ul> -<li><a href="https://github.com/mj1856/GeoTimeZone">GeoTimeZone</a> is -written in <a -href="https://en.wikipedia.org/wiki/C_Sharp_(programming_language)">C#</a> -and is freely available under the <abbr>MIT</abbr> license.</li> -<li>The <a href="https://github.com/bradfitz/latlong">latlong package</a> -is written in Go and is freely available under the Apache License.</li> -<li><a href="https://github.com/drtimcooper/LatLongToTimezone">LatLongToTimezone</a>, -in both Java and -<a href="https://en.wikipedia.org/wiki/Swift_(programming_language)">Swift</a> -form, is freely available under the MIT license.</li> -<li>For Node.js, -the <a href="https://www.npmjs.com/package/geo-tz">geo-tz module</a> -is freely available under the MIT license, and -the <a href="https://www.npmjs.com/package/tz-lookup">tz-lookup module</a> -is in the public domain.</li> -<li>The <a -href="https://github.com/MrMinimal64/timezonefinder">timezonefinder</a> -library for Python is freely available under the MIT license. -<li>The <a -href="https://github.com/gunyarakun/timezone_finder">timezone_finder</a> -library for Ruby is freely available under the MIT license.</li> -</ul></li> +Open Database License</a>. The borders appear to be quite accurate. +Its main web page lists more than twenty libraries +for looking up a timezone name from a GPS coordinate.</li> <li>Free access via a network API, if you register a key, is provided by the <a href="https://www.geonames.org/export/web-services.html#timezone">GeoNames @@ -833,7 +810,7 @@ Divisions of Countries ("Statoids")</a> lists political subdivision data related to time zones.</li> <li><a href="https://manifold.net/info/freestuff.shtml">Manifold Software – GIS and Database Tools</a> includes a Manifold-format map of -world time zone boundaries distributed under the +world time zone boundaries circa 2007, distributed under the <abbr>GPL</abbr>.</li> <li>A ship within the <a href="https://en.wikipedia.org/wiki/Territorial_waters">territorial @@ -1133,9 +1110,12 @@ might be redefined without Leap Seconds</a> gives pointers on this contentious issue. The General Conference on Weights and Measures -<a href="https://www.bipm.org/en/cgpm-2022/resolution-4">voted in 2022</a> +<a href="https://www.bipm.org/en/cgpm-2022/resolution-4">decided in 2022</a> to discontinue the use of leap seconds by 2035, replacing them with an as-yet-undetermined scheme some time after the year 2135. +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. </li> </ul> </section> -- 2.40.1

2 3

[tz-announce] 2024a release of tz code and data available
by Paul Eggert via tz-announce Feb. 1, 2024

Feb. 1, 2024

The 2024a release of the tz code and data is available. This release contains the following changes: Briefly: Kazakhstan unifies on UTC+5 beginning 2024-03-01. Palestine springs forward a week later after Ramadan. zic no longer pretends to support indefinite-past DST. localtime no longer mishandles Ciudad Juárez in 2422. Changes to future timestamps Kazakhstan unifies on UTC+5. This affects Asia/Almaty and Asia/Qostanay which together represent the eastern portion of the country that will transition from UTC+6 on 2024-03-01 at 00:00 to join the western portion. (Thanks to Zhanbolat Raimbekov.) Palestine springs forward a week later than previously predicted in 2024 and 2025. (Thanks to Heba Hamad.) Change spring-forward predictions to the second Saturday after Ramadan, not the first; this also affects other predictions starting in 2039. Changes to past timestamps Asia/Ho_Chi_Minh's 1955-07-01 transition occurred at 01:00 not 00:00. (Thanks to Đoàn Trần Công Danh.) From 1947 through 1949, Toronto's transitions occurred at 02:00 not 00:00. (Thanks to Chris Walton.) In 1911 Miquelon adopted standard time on June 15, not May 15. Changes to code The FROM and TO columns of Rule lines can no longer be "minimum" or an abbreviation of "minimum", because TZif files do not support DST rules that extend into the indefinite past - although these rules were supported when TZif files had only 32-bit data, this stopped working when 64-bit TZif files were introduced in 1995. This should not be a problem for realistic data, since DST was first used in the 20th century. As a transition aid, FROM columns like "minimum" are now diagnosed and then treated as if they were the year 1900; this should suffice for TZif files on old systems with only 32-bit time_t, and it is more compatible with bugs in 2023c-and-earlier localtime.c. (Problem reported by Yoshito Umaoka.) localtime and related functions no longer mishandle some timestamps that occur about 400 years after a switch to a time zone with a DST schedule. In 2023d data this problem was visible for some timestamps in November 2422, November 2822, etc. in America/Ciudad_Juarez. (Problem reported by Gilmore Davidson.) strftime %s now uses tm_gmtoff if available. (Problem and draft patch reported by Dag-Erling Smørgrav.) Changes to build procedure The leap-seconds.list file is now copied from the IERS instead of from its downstream counterpart at NIST, as the IERS version is now in the public domain too and tends to be more up-to-date. (Thanks to Martin Burnicki for liaisoning with the IERS.) Changes to documentation The strftime man page documents which struct tm members affect which conversion specs, and that tzset is called. (Problems reported by Robert Elz and Steve Summit.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2024a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2024a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2024a.tar.lz The following convenience links are also available, although they may point to the previous release until the relevant caches are refreshed: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit 380c07cef01c71c1f93e9709d9f8c79b91cff063 dated 2024-02-01 09:28:56 -0800 and tagged '2024a' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 46da8bfa762c7d109db93e5c060789097fc0e1e38bdad5bb8fec886ef47f138bd03b913a743cd5f7e23dc359a72bfd63e7ffc0de199d2b51e6a174361dbdc43c tzcode2024a.tar.gz 1f09f1b2327cc9e1afc7e9045e83ee3377918dafe1bee2f282b6991828d03b3c70a4d3a17f9207dfb1361bb25bc214a8922a756e84fa114e9ba476226db57236 tzdata2024a.tar.gz f1a3b06ea2b28a0bf968b75f3674f3b64d8226338d42e2ed17aea33e34bff0f9a7a22f4116612e6c81b9b7b57deaee6ed01a6881000fa1042a7f4390b55a1856 tzdb-2024a.tar.lz Here are GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmW716sACgkQ7ZfpDmKq fjTCyxAAvMohPXC5+oZT9T/X0vhIkK5kJOzDF/eptBVzwxa8WDymp4q7UzGCC2Kg 57dWthckzYqrvcz3QBLagF8bFFVCrQKPiKbMZUYTin+eWrxLUDx1sHOPaxWMPFrY aHjy/HGVMa43P7wp/3iaLLwvuVmcxcWiLy5ebQbXQrFbe09KJDb6mK4ClR+1KdLd aF8BCSU6nI0KQz1bRqmHlm+J7X1ll0E8YymWoK7Ujwht8SYRqpJOqOv2XJ8g0wFO wip6p535KQ3iEIQqc25Swn4v3W26hfa2yZXMh0edgQe1uqqzV3rLi7n8sOrSYjjd uwzyVC6wADGM2PgH4dq6YOeOs9jB+wTm6MEH4/GXP0IpPNPswUnHLK/WJGTHidW4 HJ0hY50S24wMxNYiaiuSbo8Lgefky3GZKZo+umXVKlPjsSrvImaWmFH2gOqvbZIi Ujl/NjDUmH7C4UDGx/ZkLwpOwjcu28hcacLkd6ad3hnFuZhG28yKd9rdQFn6/PTL rX8uAtuJ0GOREWAQWBNKj2dnyOrE45C+EbbuSCobAzvSXMyJ9svb7WuawmhqEjf/ DXY3VJ7pEAViQ/Hqtkxp8R9JfvZ6XCL8EF18eReeJdejjVObNIoUMOyPFX5HXJbs WS8yEl63iDyzzj4Jnvu5dMv8VlWel4CBCCJSkHjtrX9PewqbGq0= =aSZf -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmW716sACgkQ7ZfpDmKq fjTkQQ/6AqS/VNV6+RbbyLbLuOzh4GvYDMq1xTxGnjj7nwr80ob/wwSVmX7Gf5xt gVgagC75EJyskY6dfUPbSHwmOx8Dk2ttQtEprhhzk+1WpUSPZoy/RYMdWN+JzO3s LekrzU86SAh7yP21qSovYRM5rW02Da5RmiLUmknzBpP2cuZsq3qSPYUEMjB3JO39 OzBq0nyLbUR9nqew/f6fcPviyweqTkZdcDsr/+jNUGDI/kezGQ0u3ExlGc0EmGU0 ISAFB7uSDWgoJlwH3ZBtI4lOxiVQRKXafFcdvmLka0hYDGOm6f2zvkhvLEHVN9xK /V680qKy1vIOkyDRp664P9qZ0951+tpb9I47ip7SLqqBoyWhlfb/SJ2eFfb3k+kx fPkCX89QsqkfSPXySJCO13YYEQXpI2VPdWi0JxDI+LD/VEHITiydrYT+afnn0iyZ bM/TKnqaQ4bhAXdLBj3oUSwFQHEgPgeLOrTmWEdN9YmO5Cwbm1gZvOKZ4u2CYW6I ZM+ZwCuNO1hqYRSoeIaN60fUOneXaOcAejlOS/bJr7hNKUtmAjsSS7S7YGeNgQld LXRDRD3vou/qIHlIhmGpTUlOBl5NXVrP42w91nBYEwNyY4lbKLw22GS4FRF1cu9+ wfMfJqY4wwDp/uDMXAfWIXU1AdMg7t1NephMIGg4mivKGYmQmvY= =CvSR -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmW7160ACgkQ7ZfpDmKq fjTlmBAAnPjG9L1PG/4AlnLSdrXhXEVirX6LlmsUjh3DRzXlHjeEHUcD+rEL+wFK cM55uo+yzD7iq1TC1FXxbVKpxFcTxtgNx6Jmz2sHYjymCUmqPFVaj2GtCEwiBaKA CioxHZuQoRaSQnsmGzM/VhC30VMPj1S8SoFNZhbhXkNr0Wxy/f8xxnwcIDRvdzOD 9DvUWqJ5W0jHg/2m4RmbTavsp6tZSdcxoe8R5Ie33tQL7Lwqsze4dkggbzdCFd11 bPhrB9l2mQ6l3KrZ+VQRthL9VJPMrkpgFNK0XiCn+8ctaJS7dFjIspcTtIUbuyiF Z4YMcOUnLdLeL0OwFP1dRNz4kVlLioAO5dfIAHjPdRF0slywcFaw4BWB81Vwwkdy BjkX8nWmFEgYy1DoDYPBf5ju5SNcafPnQ20tO3Cjyzdg57Dc4nN7rd21t6bcPWTw 8FjzOvFoeSjLmzK+4EB5Sx9r0xsP53KSNHYXG272qqkRDtKhi62KNn6ZWR9QMTM7 yIh2OC+yI6Nrp0SAR0CKZQCtM7ghjBQYJeHliW6BzCmAolRaH2Ng5Z+rFDLyxtc2 L+VWkZROyyI5dQrKTpq+pzS6LtidbkM/hyggc0GE2mqGr78f+pEHHXsNkq8xtVNX Z1HLQe0cvORQsi9wH1yNFRlwsflxfN1VHhNhNXvYdtvJLfbwr7M= =Yw45 -----END PGP SIGNATURE-----

1 0

Kazakhstan timezone switch from 01.03.2024
by Yegor Fyodorov Feb. 1, 2024

Feb. 1, 2024

Dear sirs, I want to notify you that Kazakstan's government made a decision to switch timezone for the whole country to one timezone only: UTC+5. Right now there are 2 timezones: UTC+5 and UTC+6. The switch is going to happen on 1st march 2024. As far as I can see this change is not implemented in 2023d version of timezone database. Is it possible to add this change? Kazakstan is a big country, so a lot of users will be affected. And there is only 1 month left to implement this change. Some links for the news. Unfortunatelly official news are only in Russian / Kazakh language, but you can use google translate. Kazakhstan will switch to a single time zone, UTC+05:00, on March 1, 2024: https://en.wikipedia.org/wiki/Time_in_Kazakhstan According to Ministry of Trade and Integration of the Republic of Kazakhstan website: https://www.gov.kz/memleket/entities/mti/press/news/details/688998?lang=ru -- Best regards, Yegor Fyodorov

2 1

ipr check: draft-murchison-rfc8536bis
by Eliot Lear Jan. 31, 2024

Jan. 31, 2024

Authors, Please confirm that you are not aware of any IPR associated with draft-murchison-rfc8536bis, and that you are all willing to be listed as authors. Thanks, Eliot (acting as document shepherd)

3 2

Expanding the section on the Czech Republic and Slovakia
by Ivan Benovic Jan. 31, 2024

Jan. 31, 2024

Hello, My name is Ivan Benovic, I am a native of Slovakia (former Czechoslovakia) and would like to propose several additions to the section on the Czech Republic and Slovakia. First of all, I suggest adding links to two documents: – https://www.slov-lex.sk/pravne-predpisy/SK/ZZ/1946/54/ (This is an official link to the Czechoslovak Summer Time Act of March 8, 1946 that authorizes the Czechoslovak government to set the exact dates of change to summer time and back to Central European Time. The act also implicitly confirms Central European Time as the official time zone of Czechoslovakia and currently remains in force in both the Czech Republic and Slovakia.) – https://www.psp.cz/eknih/1945pns/tisky/t0216_00.htm (This is a link to the original legislative proposal dating back to February 22, 1946. The accompanying memorandum to the proposal says that an advisory committee on European railroad transportation that met in Brussels in October 1945 decided that the change of time should be carried out in all participating countries in a strictly coordinated manner. To that end and in order to make setting the dates of summer time and standard time in Czechoslovakia more flexible, the act authorized the government to set them without parliamentary approval.) Second, I suggest expanding the Rules section. The link https://kalendar.beda.cz/kdy-zacina-a-konci-letni-cas, which is already included in the section, containts the following information that is not yet explicitly included in the rules: Year 1916: According to the excerpt from a contemporary newspaper article, in 1916 summer time started in the Czech lands (part of the then Austria-Hungary) on April 30 at 23:00 (the clock was shifted to May 1, 0:00) and lasted until October 1 at 1:00 (when the clock was shifted back to 0:00). The corresponding rule should thus look as follows: #RuleNAMEFROMTO-INONATSAVELETTER/S RuleCzech1916only-Apr3023:001:00S RuleCzech1916only-Oct11:000- Year 1917: According to the excerpt from another contemporary newspaper article, in 1917 summer time started in the Czech lands on April 16 and ended on September 17, but no exact times are given, so I guess we can’t add any rule. Year 1918: According to the excerpt from a third contemporary newspaper article on the webpage, in 1918 summer time started in the Czech lands (still part of the then Austria-Hungary) on April 15 at 1:00 (the clock was shifted to 2:00) and lasted until September 16 at 2:00 when the clock was shifted back to 1:00. The corresponding rule should thus look as follows: #RuleNAMEFROMTO-INONATSAVELETTER/S RuleCzech1918only-Apr151:001:00S RuleCzech1918only-Sep161:00 0- Afterward, unlike France and the United Kingdom, the First Czechoslovak Republic decided not to adopt summer time in the interwar period due to public opposition. Year 1940: Just like the excerpt mentioning 1917, the corresponding excerpt for 1940 doesn’t contain any exact times of the change either, so I guess I can’t suggest adding any rule, but it says that summer time started on April 1 and ended on October 6 of that year. Should you have any questions or need any clarifications, feel free to contact me. All the best, Ivan Benovic +421 910 557 4114 (WhatsApp/Signal) ivan.benovic(a)protonmail.com www.linkedin.com/in/benovic

2 1

Re: [tz] [PROPOSED] Document POSIX versions more carefully
by Paul Eggert Jan. 28, 2024

Jan. 28, 2024

On 2024-01-28 07:23, Paul Gilmartin wrote: > Is a draft of that next POSIX publicly available? You can get a copy by signing up as per the News section of: https://www.opengroup.org/austin/ > One significant(?) > UNIX-branded implementation supports only “POSIX.1-2017-like TZ strings”: > <https://www.ibm.com/docs/en/zos/3.1.0?topic=variable-command-format> Thanks, I wasn't aware that z/OS supports only POSIX.1-2017 syntax for TZ strings. This behavior was common in older platforms, and I assume can happen even today in stripped-down platforms other than z/OS. As a transition aid for these systems, it's helpful to have a mapping from TZDB settings like TZ='Europe/London' to POSIX.1-2017 approximations like TZ='GMT0BST,M3.5.0/1,M10.5.0'. Perhaps TZDB itself should support such a mapping, though now's not the best time to add that as we're so close to a release. In the meantime I installed the attached documentation patch, which references the posix_tz_db package that generates mapping tables.

2 1