- tz - lists.iana.org

[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

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

Jan. 28, 2024

Since the next POSIX will require support for TZDB Zone names in the TZ environment variable, be more careful about phrases like “POSIX-like TZ strings” in comments and documentation. Call them “POSIX.1-2017-like TZ strings” instead, to make it clearer that they’re the traditional POSIX form like TZ='GMT0BST,M3.5.0/1,M10.5.0' instead of the TZDB form like TZ='Europe/London'. --- Makefile | 19 ++++++++++--------- etcetera | 2 +- localtime.c | 16 +++++++++------- newstrftime.3 | 4 ++-- newtzset.3 | 4 ++-- private.h | 2 +- theory.html | 30 +++++++++++++++--------------- tz-link.html | 2 +- tzfile.5 | 28 +++++++++++++++------------- tzfile.h | 6 +++--- tzselect.ksh | 6 +++--- zic.8 | 10 +++++----- zic.c | 9 +++++---- 13 files changed, 72 insertions(+), 66 deletions(-) diff --git a/Makefile b/Makefile index 97a17314..d48354c7 100644 --- a/Makefile +++ b/Makefile @@ -53,7 +53,7 @@ DATAFORM= main LOCALTIME= Factory -# The POSIXRULES macro controls interpretation of POSIX-like TZ +# The POSIXRULES macro controls interpretation of POSIX-2017.1-like TZ # settings like TZ='EET-2EEST' that lack DST transition rules. # If POSIXRULES is '-', no template is installed; this is the default. # Any other value for POSIXRULES is obsolete and should not be relied on, as: @@ -274,7 +274,7 @@ LDLIBS= # -DTZ_DOMAINDIR=\"/path\" to use "/path" for gettext directory; # the default is system-supplied, typically "/usr/lib/locale" # -DTZDEFRULESTRING=\",date/time,date/time\" to default to the specified -# DST transitions for POSIX-style TZ strings lacking them, +# DST transitions for POSIX.1-2017-style TZ strings lacking them, # in the usual case where POSIXRULES is '-'. If not specified, # TZDEFRULESTRING defaults to US rules for future DST transitions. # This mishandles some past timestamps, as US DST rules have changed. @@ -340,9 +340,10 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ # guess TM_GMTOFF from other macros; define NO_TM_GMTOFF to suppress this. # Similarly, if your system has a "zone abbreviation" field, define # -DTM_ZONE=tm_zone -# and define NO_TM_ZONE to suppress any guessing. Although these two fields -# not required by POSIX, a future version of POSIX is planned to require them -# and they are widely available on GNU/Linux and BSD systems. +# and define NO_TM_ZONE to suppress any guessing. +# Although these two fields are not required by POSIX.1-2017, +# POSIX 202x/D4 requires them and they are widely available +# on GNU/Linux and BSD systems. # # The next batch of options control support for external variables # exported by tzcode. In practice these variables are less useful @@ -352,7 +353,7 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ # # -DHAVE_TZNAME=0 # do not support "tzname" # # -DHAVE_TZNAME=1 # support "tzname", which is defined by system library # # -DHAVE_TZNAME=2 # support and define "tzname" -# # to the "CFLAGS=" line. "tzname" is required by POSIX 1988 and later. +# # to the "CFLAGS=" line. "tzname" is required by POSIX.1-1988 and later. # # If not defined, the code attempts to guess HAVE_TZNAME from other macros. # # Warning: unless time_tz is also defined, HAVE_TZNAME=1 can cause # # crashes when combined with some platforms' standard libraries, @@ -362,8 +363,8 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ # # -DUSG_COMPAT=0 # do not support # # -DUSG_COMPAT=1 # support, and variables are defined by system library # # -DUSG_COMPAT=2 # support and define variables -# # to the "CFLAGS=" line; "timezone" and "daylight" are inspired by -# # Unix Systems Group code and are required by POSIX 2008 (with XSI) and later. +# # to the "CFLAGS=" line; "timezone" and "daylight" are inspired by Unix +# # Systems Group code and are required by POSIX.1-2008 and later (with XSI). # # If not defined, the code attempts to guess USG_COMPAT from other macros. # # # # To support the external variable "altzone", add @@ -427,7 +428,7 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ # The name of a POSIX-like library archiver, its flags, C compiler, # linker flags, and 'make' utility. Ordinarily the defaults suffice. -# The commented-out values are the defaults specified by POSIX 202x/D3. +# The commented-out values are the defaults specified by POSIX.1-202x/D4. #AR = ar #ARFLAGS = -rv #CC = c17 diff --git a/etcetera b/etcetera index 865a220c..29fbed9b 100644 --- a/etcetera +++ b/etcetera @@ -5,7 +5,7 @@ # These entries are for uses not otherwise covered by the tz database. # Their main practical use is for platforms like Android that lack -# support for POSIX-style TZ strings. On such platforms these entries +# support for POSIX.1-2017-style TZ strings. On such platforms these entries # can be useful if the timezone database is wrong or if a ship or # aircraft at sea is not in a timezone. diff --git a/localtime.c b/localtime.c index 7613769f..02cc5ee5 100644 --- a/localtime.c +++ b/localtime.c @@ -7,7 +7,7 @@ /* ** Leap second handling from Bradley White. -** POSIX-style TZ environment variable handling from Guy Harris. +** POSIX.1-1988 style TZ environment variable handling from Guy Harris. */ /*LINTLIBRARY*/ @@ -106,7 +106,7 @@ static char const UNSPEC[] = "-00"; for ttunspecified to work without crashing. */ enum { CHARS_EXTRA = max(sizeof UNSPEC, 2) - 1 }; -/* Limit to time zone abbreviation length in POSIX-style TZ strings. +/* Limit to time zone abbreviation length in POSIX.1-2017-style TZ strings. This is distinct from TZ_MAX_CHARS, which limits TZif file contents. */ #ifndef TZNAME_MAXIMUM # define TZNAME_MAXIMUM 255 @@ -935,7 +935,8 @@ getoffset(register const char *strp, int_fast32_t *const offsetp) /* ** Given a pointer into a timezone string, extract a rule in the form -** date[/time]. See POSIX section 8 for the format of "date" and "time". +** date[/time]. See POSIX Base Definitions section 8.3 variable TZ +# for the format of "date" and "time". ** If a valid rule is not found, return NULL. ** Otherwise, return a pointer to the first character not part of the rule. */ @@ -1079,7 +1080,7 @@ transtime(const int year, register const struct rule *const rulep, } /* -** Given a POSIX section 8-style TZ string, fill in the rule tables as +** Given a POSIX.1-2017-style TZ string, fill in the rule tables as ** appropriate. */ @@ -1312,8 +1313,8 @@ tzparse(const char *name, struct state *sp, struct state const *basep) /* ** Transitions from DST to DDST ** will effectively disappear since - ** POSIX provides for only one DST - ** offset. + ** POSIX.1-2017 provides for only one + ** DST offset. */ if (isdst && !sp->ttis[j].tt_ttisstd) { sp->ats[i] += dstoffset - @@ -1483,7 +1484,8 @@ tzfree(timezone_t sp) ** ** If successful and SETNAME is nonzero, ** set the applicable parts of tzname, timezone and altzone; -** however, it's OK to omit this step if the timezone is POSIX-compatible, +** however, it's OK to omit this step +** if the timezone is compatible with POSIX.1-2017 ** since in that case tzset should have already done this step correctly. ** SETNAME's type is int_fast32_t for compatibility with gmtsub, ** but it is actually a boolean and its value should be 0 or 1. diff --git a/newstrftime.3 b/newstrftime.3 index 9fc68471..704318ea 100644 --- a/newstrftime.3 +++ b/newstrftime.3 @@ -91,11 +91,11 @@ as specified by brackets in the description. If a bracketed member name is followed by .q + , .B strftime -can use the named member even though POSIX-2017 does not list it; +can use the named member even though POSIX.1-2017 does not list it; if the name is followed by .q \*- , .B strftime -ignores the member even though POSIX-2017 lists it +ignores the member even though POSIX.1-2017 lists it which means portable code should set it. For portability, .BI * timeptr diff --git a/newtzset.3 b/newtzset.3 index 5d973749..b1384f32 100644 --- a/newtzset.3 +++ b/newtzset.3 @@ -216,7 +216,7 @@ except that POSIX.1-2017 does not allow a leading sign (\c .q "\*-" or .q "+" ). -As an extension to POSIX-1.2017, the hours part of +As an extension to POSIX.1-2017, the hours part of .I time can range from \-167 through 167; this allows for unusual rules such as @@ -230,7 +230,7 @@ is not given, is Here are some examples of .I TZ values that directly specify the timezone; they use some of the -extensions to POSIX-1.2017. +extensions to POSIX.1-2017. .TP .B EST5 stands for US Eastern Standard diff --git a/private.h b/private.h index b3d563d5..0dac6af4 100644 --- a/private.h +++ b/private.h @@ -973,7 +973,7 @@ enum { /* How many years to generate (in zic.c) or search through (in localtime.c). This is two years larger than the obvious 400, to avoid edge cases. - E.g., suppose a non-POSIX rule applies from 2012 on and has transitions + E.g., suppose a non-POSIX.1-2017 rule applies from 2012 on with transitions in March and September, plus one-off transitions in November 2013. If zic looked only at the last 400 years, it would set max_year=2413, with the intent that the 400 years 2014 through 2413 will be repeated. diff --git a/theory.html b/theory.html index 0fb8d66a..318b6c25 100644 --- a/theory.html +++ b/theory.html @@ -95,7 +95,7 @@ Group Base Specifications Issue 7</a>, IEEE Std 1003.1-2017, 2018 Edition. Because the database's scope encompasses real-world changes to civil timekeeping, its model for describing time is more complex than the -standard and daylight saving times supported by POSIX. +standard and daylight saving times supported by POSIX.1-2017. A <code><abbr>tz</abbr></code> timezone corresponds to a ruleset that can have more than two changes per year, these changes need not merely flip back and forth between two alternatives, and the rules themselves @@ -187,7 +187,7 @@ in decreasing order of importance: href="https://en.wikipedia.org/wiki/ASCII">ASCII</a> letters, '<code>.</code>', '<code>-</code>' and '<code>_</code>'. Do not use digits, as that might create an ambiguity with <a - href="https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#ta…">POSIX + href="https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#ta…">POSIX.1-2017 <code>TZ</code> strings</a>. A file name component must not exceed 14 characters or start with '<code>-</code>'. @@ -378,7 +378,7 @@ nowadays distributions typically use it and no great weight should be attached to whether a link is defined in <code>backward</code> or in some other file. The source file <code>etcetera</code> defines names that may be useful -on platforms that do not support POSIX-style <code>TZ</code> strings; +on platforms that do not support POSIX.1-2017-style <code>TZ</code> strings; no other source file other than <code>backward</code> contains links to its zones. One of <code>etcetera</code>'s names is <code>Etc/UTC</code>, @@ -426,7 +426,7 @@ in decreasing order of importance: expression <code>[-+[:alnum:]]{3,6}</code> should match the abbreviation. This guarantees that all abbreviations could have been specified by a - POSIX <code>TZ</code> string. + POSIX.1-2017 <code>TZ</code> string. </p> </li> <li> @@ -775,7 +775,7 @@ href="https://www.dissentmagazine.org/blog/booked-a-global-history-of-time-vanes the Western 06:00 to be 12:00. These practices are largely outside the scope of the <code><abbr>tz</abbr></code> code and data, which provide only limited support for date and time localization - such as that required by POSIX. + such as that required by POSIX.1-2017. If <abbr>DST</abbr> is not used a different time zone can often do the trick; for example, in Kenya a <code>TZ</code> setting like <code><-03>3</code> or <code>America/Cayenne</code> starts @@ -872,23 +872,23 @@ input is occasionally extended, and a platform may still be shipping an older <code>zic</code>. </p> -<h3 id="POSIX">POSIX properties and limitations</h3> +<h3 id="POSIX">POSIX.1-2017 properties and limitations</h3> <ul> <li> <p> - In POSIX, time display in a process is controlled by the + In POSIX.1-2017, time display in a process is controlled by the environment variable <code>TZ</code>. - Unfortunately, the POSIX + Unfortunately, the POSIX.1-2017 <code>TZ</code> string takes a form that is hard to describe and is error-prone in practice. - Also, POSIX <code>TZ</code> strings cannot deal with daylight + Also, POSIX.1-2017 <code>TZ</code> strings cannot deal with daylight saving time rules not based on the Gregorian calendar (as in Morocco), or with situations where more than two time zone abbreviations or <abbr>UT</abbr> offsets are used in an area. </p> <p> - The POSIX <code>TZ</code> string takes the following form: + The POSIX.1-2017 <code>TZ</code> string takes the following form: </p> <p> @@ -955,7 +955,7 @@ an older <code>zic</code>. </dl> <p> - Here is an example POSIX <code>TZ</code> string for New + Here is an example POSIX.1-2017 <code>TZ</code> string for New Zealand after 2007. It says that standard time (<abbr>NZST</abbr>) is 12 hours ahead of <abbr>UT</abbr>, and that daylight saving time @@ -966,7 +966,7 @@ an older <code>zic</code>. <pre><code>TZ='NZST-12NZDT,M9.5.0,M4.1.0/3'</code></pre> <p> - This POSIX <code>TZ</code> string is hard to remember, and + This POSIX.1-2017 <code>TZ</code> string is hard to remember, and mishandles some timestamps before 2008. With this package you can use this instead: </p> @@ -1004,7 +1004,7 @@ an older <code>zic</code>. limit phone calls to off-peak hours. </li> <li> - POSIX provides no convenient and efficient way to determine + POSIX.1-2017 provides no convenient and efficient way to determine the <abbr>UT</abbr> offset and time zone abbreviation of arbitrary timestamps, particularly for timezones that do not fit into the POSIX model. @@ -1031,14 +1031,14 @@ an older <code>zic</code>. </li> </ul> -<h3 id="POSIX-extensions">Extensions to POSIX in the +<h3 id="POSIX-extensions">Extensions to POSIX.1-2017 in the <code><abbr>tz</abbr></code> code</h3> <ul> <li> <p> The <code>TZ</code> environment variable is used in generating the name of a file from which time-related information is read - (or is interpreted à la POSIX); <code>TZ</code> is no longer + (or is interpreted à la POSIX.1-2017); <code>TZ</code> is no longer constrained to be a string containing abbreviations and numeric data as described <a href="#POSIX">above</a>. The file's format is <dfn><abbr>TZif</abbr></dfn>, diff --git a/tz-link.html b/tz-link.html index 5840f48f..c6181d92 100644 --- a/tz-link.html +++ b/tz-link.html @@ -114,7 +114,7 @@ Indiana, which switched from central to eastern time in 1991 and switched back in 2006. To use the database on an extended <a href="https://en.wikipedia.org/wiki/POSIX"><abbr -title="Portable Operating System Interface">POSIX</abbr></a> +title="Portable Operating System Interface">POSIX</abbr>.1-2017</a> implementation set the <code><abbr>TZ</abbr></code> environment variable to the location's full name, e.g., <code><abbr>TZ</abbr>="America/New_York"</code>.</p> diff --git a/tzfile.5 b/tzfile.5 index 55280282..867348d6 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -85,7 +85,7 @@ described in the file is associated with the time period starting with the same-indexed transition time and continuing up to but not including the next transition time. (The last time type is present only for consistency checking with the -POSIX-style TZ string described below.) +POSIX.1-2017-style TZ string described below.) These values serve as indices into the next field. .IP \(bu .B tzh_typecnt @@ -186,7 +186,8 @@ must also be set. .PP The standard/wall and UT/local indicators were designed for transforming a TZif file's transition times into transitions appropriate -for another time zone specified via a POSIX-style TZ string that lacks rules. +for another time zone specified via +a POSIX.1-2017-style TZ string that lacks rules. For example, when TZ="EET\*-2EEST" and there is no TZif file "EET\*-2EEST", the idea was to adapt the transition times from a TZif file with the well-known name "posixrules" that is present only for this purpose and @@ -215,13 +216,14 @@ the above header and data are followed by a second header and data, identical in format except that eight bytes are used for each transition time or leap second time. (Leap second counts remain four bytes.) -After the second header and data comes a newline-enclosed, -POSIX-TZ-environment-variable-style string for use in handling instants +After the second header and data comes a newline-enclosed string +in the style of the contents of a POSIX.1-2017 TZ environment variable, +for use in handling instants after the last transition time stored in the file or for all instants if the file has no transitions. -The POSIX-style TZ string is empty (i.e., nothing between the newlines) -if there is no POSIX-style representation for such instants. -If nonempty, the POSIX-style TZ string must agree with the local time +The TZ string is empty (i.e., nothing between the newlines) +if there is no POSIX.1-2017-style representation for such instants. +If nonempty, the TZ string must agree with the local time type after the last transition time if present in the eight-byte data; for example, given the string .q "WET0WEST,M3.5.0/1,M10.5.0" @@ -233,8 +235,8 @@ Also, if there is at least one transition, time type 0 is associated with the time period from the indefinite past up to but not including the earliest transition time. .SS Version 3 format -For version-3-format timezone files, the POSIX-TZ-style string may -use two minor extensions to the POSIX TZ format, as described in +For version-3-format timezone files, the TZ string may +use two minor extensions to the POSIX.1-2017 TZ format, as described in .BR newtzset (3). First, the hours part of its transition times may be signed and range from \-167 through 167 instead of the POSIX-required unsigned values @@ -352,7 +354,7 @@ version 2+ data even if the reader's native timestamps have only .IP \(bu Some readers designed for version 2 might mishandle timestamps after a version 3 or higher file's last transition, because -they cannot parse extensions to POSIX in the TZ-like string. +they cannot parse extensions to POSIX.1-2017 in the TZ-like string. As a partial workaround, a writer can output more transitions than necessary, so that only far-future timestamps are mishandled by version 2 readers. @@ -403,7 +405,7 @@ Some readers mishandle a transition if its timestamp has the minimum possible signed 64-bit value. Timestamps less than \-2**59 are not recommended. .IP \(bu -Some readers mishandle POSIX-style TZ strings that +Some readers mishandle TZ strings that contain .q "<" or @@ -431,12 +433,12 @@ Some readers mishandle TZif files that specify daylight-saving time UT offsets that are less than the UT offsets for the corresponding standard time. These readers do not support locations like Ireland, which -uses the equivalent of the POSIX TZ string +uses the equivalent of the TZ string .q "IST\*-1GMT0,M10.5.0,M3.5.0/1", observing standard time (IST, +01) in summer and daylight saving time (GMT, +00) in winter. As a partial workaround, a writer can output data for the -equivalent of the POSIX TZ string +equivalent of the TZ string .q "GMT0IST,M3.5.0/1,M10.5.0", thus swapping standard and daylight saving time. Although this workaround misidentifies which part of the year diff --git a/tzfile.h b/tzfile.h index 21ae37c1..3155010e 100644 --- a/tzfile.h +++ b/tzfile.h @@ -78,11 +78,11 @@ struct tzhead { ** time uses 8 rather than 4 chars, ** then a POSIX-TZ-environment-variable-style string for use in handling ** instants after the last transition time stored in the file -** (with nothing between the newlines if there is no POSIX representation for -** such instants). +** (with nothing between the newlines if there is no POSIX.1-2017 +** representation for such instants). ** ** If tz_version is '3' or greater, the above is extended as follows. -** First, the POSIX TZ string's hour offset may range from -167 +** First, the TZ string's hour offset may range from -167 ** through 167 as compared to the POSIX-required 0 through 24. ** Second, its DST start time may be January 1 at 00:00 and its stop ** time December 31 at 24:00 plus the difference between DST and diff --git a/tzselect.ksh b/tzselect.ksh index c56bc822..38941bbc 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -438,7 +438,7 @@ while eval ' doselect '"$quoted_continents"' \ "coord - I want to use geographical coordinates." \ - "TZ - I want to specify the timezone using the POSIX TZ format." \ + "TZ - I want to specify the timezone using a POSIX.1-2017 TZ string." \ "time - I know local time already." \ "now - Like \"time\", but configure only for timestamps from now on." continent=$select_result @@ -462,7 +462,7 @@ while case $continent in TZ) - # Ask the user for a POSIX TZ string. Check that it conforms. + # Ask the user for a POSIX.1-2017 TZ string. Check that it conforms. check_POSIX_TZ_string=' BEGIN { tz = substr(ARGV[1], 2) @@ -492,7 +492,7 @@ while read tz $AWK "$check_POSIX_TZ_string" ="$tz" do - say >&2 "'$tz' is not a conforming POSIX timezone string." + say >&2 "'$tz' is not a conforming POSIX.1-2017 timezone string." done TZ_for_date=$tz;; *) diff --git a/zic.8 b/zic.8 index 2f274d7b..0ad373a2 100644 --- a/zic.8 +++ b/zic.8 @@ -171,7 +171,7 @@ boundaries, particularly if causes a TZif file to contain explicit entries for .RI pre- hi transitions rather than concisely representing them -with an extended POSIX TZ string. +with an extended POSIX.1-2017 TZ string. Also see the .B "\*-b slim" option for another way to shrink output size. @@ -181,10 +181,10 @@ Generate redundant trailing explicit transitions for timestamps that occur less than .I hi seconds since the Epoch, even though the transitions could be -more concisely represented via the extended POSIX TZ string. +more concisely represented via the extended POSIX.1-2017 TZ string. This option does not affect the represented timestamps. Although it accommodates nonstandard TZif readers -that ignore the extended POSIX TZ string, +that ignore the extended POSIX.1-2017 TZ string, it increases the size of the altered output files. .TP .BI "\*-t " file @@ -245,10 +245,10 @@ for .PP The output file does not contain all the information about the long-term future of a timezone, because the future cannot be summarized as -an extended POSIX TZ string. For example, as of 2023 this problem +an extended POSIX.1-2017 TZ string. For example, as of 2023 this problem occurs for Morocco's daylight-saving rules, as these rules are based on predictions for when Ramadan will be observed, something that -an extended POSIX TZ string cannot represent. +an extended POSIX.1-2017 TZ string cannot represent. .PP The output contains data that may not be handled properly by client code designed for older diff --git a/zic.c b/zic.c index 70e8f0c7..00f00e30 100644 --- a/zic.c +++ b/zic.c @@ -2982,7 +2982,7 @@ rule_cmp(struct rule const *a, struct rule const *b) return a->r_dayofmonth - b->r_dayofmonth; } -/* Store into RESULT a POSIX TZ string that represent the future +/* Store into RESULT a POSIX.1-2017 TZ string that represent the future predictions for the zone ZPFIRST with ZONECOUNT entries. Return a compatibility indicator (a TZDB release year) if successful, a negative integer if no such TZ string exissts. */ @@ -3177,7 +3177,8 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) if (noise) { if (!*envvar) warning("%s %s", - _("no POSIX environment variable for zone"), + _("no POSIX.1-2017 environment variable" + " for zone"), zpfirst->z_name); else if (compat != 0) { /* Circa-COMPAT clients, and earlier clients, might @@ -3440,8 +3441,8 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) } if (do_extend) { /* - ** If we're extending the explicitly listed observations - ** for 400 years because we can't fill the POSIX-TZ field, + ** If we're extending the explicitly listed observations for + ** 400 years because we can't fill the POSIX.1-2017 TZ field, ** check whether we actually ended up explicitly listing ** observations through that period. If there aren't any ** near the end of the 400-year period, add a redundant -- 2.40.1

1 0

possible change to daylight saving rules in Palestine
by Paul Eggert Jan. 24, 2024

Jan. 24, 2024

Thank you for letting me know that the Palestinian cabinet is scheduled to respond this week to your address to them about daylight saving time during Ramadan. It would be convenient for cell phones and computers using the TZDB database if the cabinet decides to spring forward on April 13 at 02:00, and fall back on October 26 at 02:00, as that is what is predicted in TZDB. If the cabinet decides differently, I appreciate your offer to let us know as soon as possible. We are planning to issue a new TZDB release soon. It'd be helpful if any changes for Palestine could be incorporated in this new release, so that downstream users don't have the hassle of dealing with extra releases. I will cc this message to the tz mailing list to let people there know about this possible effect on our release schedule. If the cabinet needs reminding, I'll mention again that it's helpful to get a year's notice about unexpected changes, as discussed here: https://www.icann.org/en/blogs/details/how-time-zones-are-coordinated-13-03…

1 0

[PROPOSED] Update link to Palestine MTIT
by Paul Eggert Jan. 24, 2024

Jan. 24, 2024

* tz-link.html: Update link --- tz-link.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tz-link.html b/tz-link.html index 93c047cb..5840f48f 100644 --- a/tz-link.html +++ b/tz-link.html @@ -930,7 +930,7 @@ 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/Site/TimeZoon" +href="https://mtit.pna.ps/home/TimeZone" hreflang="ar">history of clock changes (in Arabic)</a>.</dd> <dt>Portugal</dt> <dd>The Lisbon Astronomical Observatory publishes a -- 2.40.1

1 0

Re: [tz] Time zone offset changing in Almaty and Qostanay, Kazakhstan
by Andrey.Kazakevich＠erg.kz Jan. 24, 2024

Jan. 24, 2024

Hello! How I can know when this change will be released? Have you some tracking or history of changes in database?

2 1

Washington state to permanent standard time?
by Arthur David Olson Jan. 24, 2024

Jan. 24, 2024

"Washington’s latest daylight saving time proposal would mean earlier summer sunsets." https://washingtonstatestandard.com/2024/01/16/washingtons-latest-daylight-… The article notes that Washington state adopted permanent daylight saving time in 2019, contingent on federal approval; that approval not having been provided, the current proposal is to use standard time year-round (a switch that does not require federal approval but allows the state to "ditch the switch"). The bill text is available at... https://app.leg.wa.gov/committeeschedules/Home/Document/264443#toolbar=0&na… ...and includes "...this act takes effect on November 4, 2024." (Meanwhile, I've yet to find the introduction of a time-change bill in the Maryland legislature; bills have been introduced the last few years.) @dashado

2 1

Time zone offset changing in Almaty and Qostanay, Kazakhstan
by Alexandr Uskov Jan. 24, 2024

Jan. 24, 2024

Hello, According act of the Government of the Republic of Kazakhstan from 2024-01-19 #20 (https://adilet.zan.kz/rus/docs/P2400000020 (russian language)) time offset for zones Asia/Almaty and Asia/Qostanay from Mar 1st 2024 00:00 (local time) must be set to UTC+5 instead of UTC+6. ~~~ wbr, Alexandr Uskov

2 1

Kazach
by Alexey Sharkov (KZ) Jan. 24, 2024

Jan. 24, 2024

Hello Decree of the Government of the Republic of Kazakhstan dated November 23, 2000 No. 1749 https://adilet.zan.kz/rus/docs/P2400000020 (Russian lang) 3-1. Акиматам городов Астаны, Алматы, Шымкента, Акмолинской, Алматинской, Жамбылской, Карагандинской, Костанайской, Павлодарской, Северо-Казахстанской, Туркестанской, Восточно-Казахстанской областей и областей Абай, Жетісу, Ұлытау в ночь с 29 февраля 2024 года на 1 марта 2024 года (в 00:00 часов) перевести местное время на 1 час назад.". For all Kazakhstan zones set local time back 1 hour night of February 29, 2024 to March 1, 2024 (at 00:00 hours) Zone Asia/Almaty Zone Asia/Qyzylorda Zone Asia/Qostanay Zone Asia/Aqtobe Zone Asia/Aqtau Zone Asia/Atyrau Zone Asia/Oral Internal Home Credit Bank Kazakhstan

1 0

strftime %s
by Dag-Erling Smørgrav Jan. 24, 2024

Jan. 24, 2024

Currently, strftime() implements %s by calling mktime() and then printing the result. This is fine when the struct tm passed to strftime() came from localtime() but not when it didn't. A better solution would be to call timegm() and then manually adjust the result. Of course that's only possible in the TM_GMTOFF case but that's still better than nothing. The first attachment is a program which demonstrates the issue. It should print the same value for %s in both cases but doesn't: % cc -Wall -Wextra -o strftime_s strftime_s.c % ./strftime_s local 1704903586 2024-01-10 17:19:46 CET gm 1704899986 2024-01-10 16:19:46 UTC The second attachment is my proposed fix. DES -- Dag-Erling Smørgrav - des(a)des.no

14 69

[PROPOSED 1/2] Update some tz-link links
by Paul Eggert Jan. 22, 2024

Jan. 22, 2024

* tz-link.html: Update some citations and remove some that no longer work. --- asia | 4 ++-- australasia | 2 +- tz-link.html | 33 ++++++++++++++------------------- 3 files changed, 17 insertions(+), 22 deletions(-) diff --git a/asia b/asia index a2055e6d..1a6fa4f8 100644 --- a/asia +++ b/asia @@ -3620,7 +3620,7 @@ Zone Asia/Hebron 2:20:23 - LMT 1900 Oct # Philippines -# From Paul Eggert (2018-11-18): +# From Paul Eggert (2024-01-21): # The Spanish initially used American (west-of-Greenwich) time. # It is unknown what time Manila kept when the British occupied it from # 1762-10-06 through 1764-04; for now assume it kept American time. @@ -3628,7 +3628,7 @@ Zone Asia/Hebron 2:20:23 - LMT 1900 Oct # Philippines, issued a proclamation announcing that 1844-12-30 was to # be immediately followed by 1845-01-01; see R.H. van Gent's # History of the International Date Line -# https://www.staff.science.uu.nl/~gent0113/idl/idl_philippines.htm +# https://webspace.science.uu.nl/~gent0113/idl/idl_philippines.htm # The rest of the data entries are from Shanks & Pottenger. # From Jesper Nørgaard Welen (2006-04-26): diff --git a/australasia b/australasia index a9e9eb4a..0e9c2592 100644 --- a/australasia +++ b/australasia @@ -2043,7 +2043,7 @@ Zone Pacific/Efate 11:13:16 - LMT 1912 Jan 13 # Vila # ordaining - by a masterpiece of diplomatic flattery - that # the Fourth of July should be celebrated twice in that year." # This happened in 1892, according to the Evening News (Sydney) of 1892-07-20. -# https://www.staff.science.uu.nl/~gent0113/idl/idl.htm +# https://webspace.science.uu.nl/~gent0113/idl/idl_alaska_samoa.htm # Although Shanks & Pottenger says they both switched to UT -11:30 # in 1911, and to -11 in 1950. many earlier sources give -11 diff --git a/tz-link.html b/tz-link.html index 84bea935..93c047cb 100644 --- a/tz-link.html +++ b/tz-link.html @@ -362,9 +362,6 @@ lets you see the <code><abbr>TZ</abbr></code> values directly.</li> <li><a href="https://www.convertit.com/Go/ConvertIt/World_Time/Current_Time.ASP">Current Time in 1000 Places</a> uses descriptions of the values.</li> -<li><a href="https://home.kpn.nl/vanadovv/time/TZworld.html">Complete -timezone information for all countries</a> -displays tables of <abbr>DST</abbr> rules. <li><a href="https://www.timeanddate.com/worldclock/">The World Clock – Worldwide</a> lets you sort zone names and convert times.</li> <li><a href="https://24timezones.com">24TimeZones</a> has a world @@ -666,9 +663,7 @@ available under a <abbr>BSD</abbr>-style license.</li> <ul> <li><a href="https://foxclocks.org">FoxClocks</a> is an extension for <a href="https://www.google.com/chrome/">Google -Chrome</a> and for <a -href="https://wiki.mozilla.org/Modules/Toolkit">Mozilla -Toolkit</a> applications like <a +Chrome</a>, <a href="https://www.mozilla.org/en-US/firefox/new/">Firefox</a> and <a href="https://www.mozilla.org/en-US/thunderbird/">Thunderbird</a>. It displays multiple clocks in the application window, and has a mapping @@ -826,9 +821,6 @@ coordinates?</a>" discusses other geolocation possibilities.</li> <li><a href="http://statoids.com/statoids.html">Administrative Divisions of Countries ("Statoids")</a> lists political subdivision data related to time zones.</li> -<li><a href="https://home.kpn.nl/vanadovv/time/Multizones.html">Time -zone boundaries for multizone countries</a> summarizes legal -boundaries between time zones within countries.</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 @@ -862,7 +854,7 @@ Lords</a> discusses how authoritarians manipulate civil time.</li> <li><a href="https://www.w3.org/TR/timezone/">Working with Time Zones</a> contains guidelines and best practices for software applications that deal with civil time.</li> -<li><a href="https://www.staff.science.uu.nl/~gent0113/idl/idl.htm">A History of +<li><a href="https://webspace.science.uu.nl/~gent0113/idl/idl.htm">A History of the International Date Line</a> tells the story of the most important time zone boundary.</li> <li><a href="http://statoids.com/tconcept.html">Basic Time @@ -875,7 +867,7 @@ Zone Concepts</a> discusses terminological issues behind time zones.</li> <dl> <dt>Australia</dt> <dd>The Parliamentary Library commissioned a <a -href="https://www.aph.gov.au/binaries/library/pubs/rp/2009-10/10rp10.pdf">research +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 href="http://www.bom.gov.au/climate/averages/tables/dst_times.shtml">Implementation @@ -883,9 +875,9 @@ Dates of Daylight Savings Time within Australia</a>.</dd> <dt>Belgium</dt> <dd>The Royal Observatory of Belgium maintains a table of time in Belgium (in -<a href="https://www.astro.oma.be/GENERAL/INFO/nli001a.html" +<a href="https://robinfo.oma.be/nl/astro-info/tijd/" hreflang="nl">Dutch</a> and <a -href="https://www.astro.oma.be/GENERAL/INFO/fri001a.html" +href="https://robinfo.oma.be/fr/astro-info/heure/" hreflang="fr">French</a>).</dd> <dt>Brazil</dt> <dd>The Time Service Department of the National Observatory @@ -929,7 +921,7 @@ Congress has published a <a href="https://www.diputados.gob.mx/bibliot/publica/inveyana/polisoc/horver/index.…" hreflang="es">history of Mexican local time (in Spanish)</a>.</dd> <dt>Netherlands</dt> -<dd><a href="https://www.staff.science.uu.nl/~gent0113/wettijd/wettijd.htm" +<dd><a href="https://webspace.science.uu.nl/~gent0113/wettijd/wettijd.htm" hreflang="nl">Legal time in the Netherlands (in Dutch)</a> covers the history of local time in the Netherlands from ancient times.</dd> <dt>New Zealand</dt> @@ -986,14 +978,17 @@ 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> +daylight saving save electricity? A meta-analysis</a>. <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. It is time to abolish the clock change and adopt permanent -standard time in the United States: a Sleep Research Society position statement. +<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 @@ -1002,13 +997,13 @@ advocates permanent standard time due to its health benefits. <a href="https://jcsm.aasm.org/doi/10.5664/jcsm.10898">Permanent standard time is the optimal choice for health and safety: an American Academy of Sleep Medicine position statement</a>. -<em>J Clin Sleep Med.</em> 2023-10-31. +<em>J Clin Sleep Med.</em> 2024;20(1):121–125. doi:<a href="https://doi.org/10.5664/jcsm.10898">10.5664/jcsm.10898</a>. The AASM argues for permanent standard time due to health and safety risks and economic costs of both <abbr>DST</abbr> transitions and permanent <abbr>DST</abbr>.</li> <li>Roenneberg T, Wirz-Justice A, Skene DJ <em>et al</em>. -<a href="https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7205184/">Why +<a href="https://journals.sagepub.com/doi/10.1177/0748730419854197">Why should we abolish Daylight Saving Time?</a> <em>J Biol Rhythms.</em> 2019;34(3):227–230. doi:<a href="https://doi.org/10.1177/0748730419854197">10.1177/0748730419854197</a>. -- 2.40.1

1 1