- tz - lists.iana.org

[PROPOSED] Update some URLs
by Paul Eggert May 9, 2024

May 9, 2024

--- theory.html | 2 +- tz-link.html | 40 +++++++++++++++++++--------------------- 2 files changed, 20 insertions(+), 22 deletions(-) diff --git a/theory.html b/theory.html index 5cb80d99..50e9ee4d 100644 --- a/theory.html +++ b/theory.html @@ -1088,7 +1088,7 @@ an older <code>zic</code>. and <code>localtime_rz</code> and <code>mktime_z</code> are like <code>localtime_r</code> and <code>mktime</code> with an extra <code>timezone_t</code> argument. - The functions were inspired by <a href="https://netbsd.org/">NetBSD</a>. + The functions were inspired by <a href="https://netbsd.org">NetBSD</a>. </li> <li> Negative <code>time_t</code> values are supported, on systems diff --git a/tz-link.html b/tz-link.html index 162d63ce..c6d96101 100644 --- a/tz-link.html +++ b/tz-link.html @@ -81,7 +81,7 @@ C Library</a> (used in title="Berkeley Software Distribution">BSD</abbr></a>, <a href="https://netbsd.org">Net<abbr>BSD</abbr></a>, <a href="https://www.openbsd.org">Open<abbr>BSD</abbr></a>, -<a href="https://www.chromium.org/chromium-os/">Chromium OS</a>, +<a href="https://www.chromium.org/chromium-os/">ChromiumOS</a>, <a href="https://cygwin.com">Cygwin</a>, <a href="https://mariadb.org">MariaDB</a>, <a href="https://en.wikipedia.org/wiki/MINIX">MINIX</a>, @@ -211,7 +211,7 @@ href="https://mm.icann.org/mailman/listinfo/tz">subscribe</a> to it and browse the <a href="https://mm.icann.org/pipermail/tz/">archive of old messages</a>. -<a href="https://tzdata-meta.timtimeonline.com/">Metadata for mailing list +<a href="https://tzdata-meta.timtimeonline.com">Metadata for mailing list discussions</a> and corresponding data changes can be generated <a href="https://github.com/timparenti/tzdata-meta">automatically</a>. </p> @@ -226,7 +226,7 @@ the process by tailoring the generic instructions in the <code><abbr>tz</abbr> README</code> file and installing the latest data yourself. System-specific instructions for installing the latest <code><abbr>tz</abbr></code> data have also been published -for <a href="https://developer.ibm.com/articles/au-aix-olson-time-zone/"><abbr>AIX</abbr></a>, +for <a href="https://www.ibm.com/support/pages/aix-time-zone-olson-tzdata-updates"><abbr>AIX</abbr></a>, <a href="https://source.android.com/devices/tech/config/timezone-rules">Android</a>, <a @@ -248,7 +248,7 @@ with lines terminated by <a href="https://en.wikipedia.org/wiki/Newline"><abbr title="linefeed">LF</abbr></a>, which can be modified by common text editors such as <a href="https://www.gnu.org/software/emacs/">GNU Emacs</a>, -<a href="https://wiki.gnome.org/Apps/Gedit">gedit</a>, and +<a href="https://gedit-technology.github.io/apps/gedit/">gedit</a>, and <a href="https://www.vim.org">vim</a>. Specialized source-file editing can be done via the <a href="https://packagecontrol.io/packages/zoneinfo">Sublime @@ -400,7 +400,7 @@ variant <a href="https://datatracker.ietf.org/doc/html/rfc6321">xCal</a> title="Extensible Markup Language">XML</abbr></a> format, and a variant <a href="https://datatracker.ietf.org/doc/html/rfc7265">jCal</a> (Internet <abbr>RFC</abbr> 7265) -uses <a href="https://www.json.org"><abbr +uses <a href="https://www.json.org/json-en.html"><abbr title="JavaScript Object Notation">JSON</abbr></a> format.</li> </ul> </section> @@ -440,11 +440,9 @@ transition in the <code><abbr>tz</abbr></code> database.</li> <li>The <a href="https://howardhinnant.github.io/date/tz.html">Time Zone Database Parser</a> is a <a href="https://en.wikipedia.org/wiki/C++">C++</a> parser and -runtime library with <a -href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0355r7.html">API</a> -adopted by -<a href="https://en.wikipedia.org/wiki/C++20">C++20</a>, -the current iteration of the C++ standard. +runtime library with a <a +href="https://en.cppreference.com/w/cpp/chrono"><code>std::chrono</code> API</a> +that is a standard part of C++. It is freely available under the <abbr title="Massachusetts Institute of Technology">MIT</abbr> license.</li> <li><a id="ICU" href="https://icu.unicode.org">International Components for @@ -467,8 +465,8 @@ freely available under the <abbr>MIT</abbr> license.</li> <li>The <a href="https://www.oracle.com/java/technologies/javase/tzupdater-readme.html">TZUpdater tool</a> compiles <code><abbr>tz</abbr></code> source into the format used by -<a href="https://openjdk.java.net/">OpenJDK</a> and -<a href="https://jdk.java.net/">Oracle JDK</a>. +<a href="https://openjdk.org">OpenJDK</a> and +<a href="https://jdk.java.net">Oracle JDK</a>. Although its source code is proprietary, its executable is available under the <a href="https://www.oracle.com/a/tech/docs/tzupdater-lic.html">Java SE Timezone Updater License Agreement</a>.</li> @@ -490,7 +488,7 @@ are alternatives to TZUpdater. IANA Updater's license is unclear; ZIUpdater is licensed under the <abbr>GPL</abbr>.</li> <li><a href="https://github.com/MenoData/Time4A">Time4A: Advanced date and time library for Android</a> and -<a href="https://github.com/MenoData/Time4J/">Time4J: Advanced date, +<a href="https://github.com/MenoData/Time4J">Time4J: Advanced date, time and interval library for Java</a> compile <code><abbr>tz</abbr></code> source into a binary format. Time4A is available under the Apache License and Time4J is @@ -516,7 +514,7 @@ many of which also support runtimes lacking the <code>timeZone</code> option. href="https://github.com/formatjs/date-time-format-timezone"><code>Intl.DateTimeFormat</code> timezone polyfill</a> is freely available under a <abbr>BSD</abbr>-style license.</li> -<li>The <a href="https://date-fns.org/">date-fns</a> +<li>The <a href="https://date-fns.org">date-fns</a> library manipulates timezone-aware timestamps in browsers and in <a href="https://nodejs.org/en/">Node.js</a>. It is freely available under the <abbr>MIT</abbr> license.</li> @@ -552,9 +550,9 @@ objects</a> let programs access an abstract view of <code><abbr>tzdb</abbr></code> data, and are designed to replace <a href="https://codeofmatt.com/javascript-date-type-is-horribly-broken/">JavaScript's problematic <code>Date</code> objects</a> when working with dates and times. -<li><a href="https://github.com/JuliaTime/">JuliaTime</a> contains a +<li><a href="https://github.com/JuliaTime">JuliaTime</a> contains a compiler from <code><abbr>tz</abbr></code> source into -<a href="https://julialang.org/">Julia</a>. It is freely available +<a href="https://julialang.org">Julia</a>. It is freely available under the <abbr>MIT</abbr> license.</li> <li><a href="https://github.com/pavkam/tzdb"><abbr>TZDB</abbr> – <abbr>IANA</abbr> Time Zone Database for Delphi/<abbr @@ -565,7 +563,7 @@ as compiled by <a href="https://en.wikipedia.org/wiki/Delphi_(IDE)">Delphi</a> and <a href="https://en.wikipedia.org/wiki/Free_Pascal"><abbr>FPC</abbr></a>. It is freely available under a <abbr>BSD</abbr>-style license.</li> -<li><a href="http://pytz.sourceforge.net">pytz – World Timezone +<li><a href="https://pythonhosted.org/pytz/">pytz – World Timezone Definitions for Python</a> compiles <code><abbr>tz</abbr></code> source into <a href="https://www.python.org">Python</a>. It is freely available under a <abbr>BSD</abbr>-style license. @@ -649,7 +647,7 @@ that represent <code><abbr>tzdb</abbr></code> timezones. Python is freely available under the <a href="https://docs.python.org/3/license.html">Python Software Foundation License</a>. -A companion <a id="pypi-tzdata" href="https://pypi.org/">PyPI</a> module +A companion <a id="pypi-tzdata" href="https://pypi.org">PyPI</a> module <a href="https://pypi.org/project/tzdata/"><code>tzdata</code></a> supplies TZif data if the underlying system data cannot be found; it is freely available under the Apache License.</li> @@ -898,7 +896,7 @@ href="https://www.ptb.de/cms/en/fachabteilungen/abt4/fb-44/ag-441/realisation-of of Legal Time in Germany</a>.</dd> <dt>Israel</dt> <dd><a -href="https://tz.cs.huji.ac.il/">Israel Timezone Files</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> @@ -1087,9 +1085,9 @@ is well-defined for sufficiently old timestamps.</li> <code>leap-seconds.list</code>, which lists the currently known leap seconds. The <abbr>IERS</abbr> maintains this file, and a copy is distributed by <code><abbr>tzdb</abbr></code> for use by <abbr>NTP</abbr> implementations like -<a href="https://www.ntp.org/">classic +<a href="https://www.ntp.org">classic <code><abbr title="Network Time Protocol Daemon">ntpd</abbr></code></a> -and <a href="https://ntpsec.org/">NTPsec</a>. +and <a href="https://ntpsec.org">NTPsec</a>. The <code><abbr>tz</abbr></code> database also distributes leap second information in a differently-formatted <code>leapseconds</code> text file, as well as in the "<code>right</code>" configuration in binary form; for -- 2.40.1

1 0

Why is "AEST" the abbreviation for Australia/Sydney in 1900?
by Jonathan Wakely May 9, 2024

May 9, 2024

Given this snippet from tzdata.zi: Z Australia/Sydney 10:4:52 - LMT 1895 F 10 AU AE%sT 1971 R AU 1917 o - Ja 1 2s 1 D R AU 1917 o - Mar lastSu 2s 0 S R AU 1942 o - Ja 1 2s 1 D R AU 1942 o - Mar lastSu 2s 0 S R AU 1942 o - S 27 2s 1 D R AU 1943 1944 - Mar lastSu 2s 0 S R AU 1943 o - O 3 2s 1 D What should the abbreviation be for the zone in, say, 1900? Using glibc I get AEST: TZ=Australia/Sydney date --date="1900-01-01" Mon 1 Jan 00:00:00 AEST 1900 But I don't see any way to get "AEST" from the tzdata and the spec in the zic(8) man page. Prior to 1895 it is "LMT", and then from 1917-01-01 it's "AEDT", and from 1917-03-25 it's "AEST", but none of the Rule lines apply to dates before 1917, so what value of LETTER/S should be used for the AE%sT format in 1900? Glibc solves this by iterating through all the transitions for the AU rule until it finds a valid name for a transition to DST and a valid name for a transition out of DST, and then remembers those two names, which in this case gives AEDT (from 1917-01-01 to 1917-03-25) and AEST (from 1917-03-25 to 1942-01-01). Then when it finds the info for a date in 1900 it looks at the isdst field of struct tm for that date, and picks one of the two remembered names, which gives us "AEST". That seems like the correct result, but nothing in the zic man page (or any other docs I can find) says that is what's supposed to happen. My code for GCC's C++ library is an independent implementation based on the spec, and it has no way to produce "AEST" for 1900. It seems to me that either the spec should to do ... something ... so that a LETTER/S field for the Rule can be found, or there should be a Zone continuation line in the tzdata that explicitly says that Australia/Sydney is always on standard time for the period 1895-02-01 to 1917-01-01 and that the abbreviation is AEST (without any %s that needs to be expanded). So add the second line here: Z Australia/Sydney 10:4:52 - LMT 1895 F 10 - AEST 1917 10 AU AE%sT 1971 R AU 1917 o - Ja 1 2s 1 D R AU 1917 o - Mar lastSu 2s 0 S R AU 1942 o - Ja 1 2s 1 D R AU 1942 o - Mar lastSu 2s 0 S R AU 1942 o - S 27 2s 1 D R AU 1943 1944 - Mar lastSu 2s 0 S R AU 1943 o - O 3 2s 1 D I'm sure this question could also be asked of many other zones, Australia/Sydney just happens to be the one I was testing with and noticed that my code couldn't expand the %s in "AE%sT". Am I missing something that says to use "S" as the LETTER/S field for dates prior to the first DST transition in 1917? What logic do other C libraries use to get "AEST" here?

6 20

Does Egypt spring forward tomorrow at 00:01 not 00:00?
by Paul Eggert April 25, 2024

April 25, 2024

Two recent news reports say that Egyptian clocks spring forward tomorrow at 00:01, not at 00:00 as per TZDB. Both cite Law No. 24 of 2023. Does anybody on this list have access to the text of that Egyptian law? I am unable to find a copy of that law online; <https://guides.loc.gov/law-egypt/legislative> points me at <https://www.egypt.gov.eg/english/laws/default.aspx> but www.egypt.gov.eg (41.33.95.166) is inaccessible to me (no packets seem to get through). I am mildly inclined to think that the distinction between 00:00 and 00:01 is being done by the news sources in question and not by the actual law. However, if someone can get a copy of the legislation that should be definitive. Here are the two sources giving spring-forward and fall-back times that differ by one minute from TZDB: * Egypt prepares to implement daylight saving time last Friday of April, Egypt Today, 2024-04-22 <https://www.egypttoday.com/Article/1/131747/Egypt-prepares-to-implement-day…> "... the current time used will be advanced by sixty minutes, starting at 12 midnight (00:01 a.m.) on Friday, April 26, until the end of the last Thursday of October at (23:59 p.m.)." * Belal Nawar, Daylight Savings in Egypt Starts on 26 April, Egyptian Streets, 2024-04-25 <https://egyptianstreets.com/2024/04/25/daylight-savings-in-egypt-starts-on-…> "The clock will be advanced by sixty minutes, starting from midnight (00:01 a.m.) on Friday 26 April, and will revert to standard time at the end of the last Thursday of October, precisely at 11:59 p.m. (23:59 p.m.)." I also see a couple of reports that we were one minute off in fall 2023: * Shereif Barakat, Egypt Bids Farewell to Daylight-Saving Time Tomorrow, Egyptian Streets, 2023-10-25 <https://egyptianstreets.com/2023/10/25/egypt-bids-farewell-to-daylight-savi…>. * Daylight Saving Time in Egypt Will End One Minute Before October 27th Scene Now, 2023-10-26 <https://scenenow.com/Buzz/Daylight-Saving-Time-in-Egypt-Will-End-One-Minute…>. On the other hand, other sources simply give transitions on the hour or on the day. Examples include <https://english.ahram.org.eg/NewsContentP/1/522092/Egypt/Summer-Time-vs-pow…> and <https://cairoscene.com/Buzz/Daylight-Saving-Time-to-Start-in-Egypt-on-Frida…>. In particular <https://www.lexology.com/library/detail.aspx?g=34fe8046-f02b-4af1-a515-30cd…>, in which an Egyptian law firm summarizes Law No. 24 (issued 16 April 2023), merely gives day boundaries. So perhaps the 00:01 and 23:59 business is merely the news sources' trying to avoid confusion.

1 0

Asia/Gaza POSIX TZ string problem
by Z Meng Chen April 22, 2024

April 22, 2024

Hi, We obtained the *tzdata2024a* from IANA. Below is the Rule for *Asia/Gaza* extracted from *tzdata2024a*: * ...* *Rule Palestine 2022 2035 - Oct Sat<=30 2:00 0 -* *Rule Palestine 2023 only - Apr 29 2:00 1:00 S* *Rule Palestine 2024 only - Apr 20 2:00 1:00 S* *Rule Palestine 2025 only - Apr 12 2:00 1:00 S* ... *Asia/Gaza POSIX TZ string (generated by zic)*: EET-2EEST, M3.4.4/50,M10.4.4/50" The rule specifies that DST in 2024 starts on April 20th. Why then does the POSIX TZ string use M3.4.4? Is this a bug? or is there any other reason? Thanks. Best regards, Meng Chen

3 5

request to update DST info for Timezone: Tehran/Iran
by Vajihe Bitarafan April 16, 2024

April 16, 2024

Hi Dear IANA, I am using some system and I encountered that in some situations Daylight Saving Time is not working correctly. >From 20 March 2023 , DST has been removed from government Policies and So from then there would not be any changes in Time. So Time zone Tehran/IRAN is +3:30 for all days of the year. I hope it will be reflected in timezone databases and I can see the Joda time is updated respectively. Thanks in advance for your help Best regards, Vajiheh Bitarafan

4 4

Vadsø, Norway mayor wants 26-hour days
by Paul Eggert April 15, 2024

April 15, 2024

On March 20 Wenche Pedersen, the mayor of Vadsø municipality, Norway, asked[1] the European Commission to issue a directive allowing Norway to create a separate time zone for the northern part of Norway. Days in the new time zone would contain 26 hours instead of the usual 24. This request is part of the "MOREtime" project. Mayor Pedersen wrote: > ... we aim to celebrate and promote this unique way of life, offering individuals the opportunity to enjoy more quality time engaging in activities such as fishing, hunting, learning new languages, or simply being with loved ones. By having our own certified time zone within the EU, we hope to attract more young people, not only from Norway but also from around the world, to discover and settle in this adventurous area. Recently the mayor's proposal has been covered by several major news organizations. When asked how the 26-hour day would actually work, the mayor replied "We haven't thought a lot about that. The clock will go from 12 to 13 ... and we have to see how this will go. I don't think they're going to say yes so we haven't thought about all the details."[2] Longtime readers of the time zone mailing list might remember that in 2019 a resident of Sommarøy, Norway petitioned his parliamentarian to abolish civil time in his town, something that also made the news.[3] However, the Sommarøy proposal was by a private individual and was easily implementable via tzdata by creating a new UTC or LMT zone with abbreviation "-00" or "LMT", whereas the Vadsø proposal is by the mayor, and would require changes to tzcode and would therefore be considerably harder to support. Although it's unlikely that the Vadsø proposal will go anywhere, it's helpful to think of how timekeeping changes like this might be accommodated by the TZDB project, as similar proposals might happen in the future. I see several ways to implement 26-hour days, falling into two major categories. Category I: Shorten civil-time hours so that there are 26 civil-time hours in a standard-length (SI) day. Four possible ways to do this are: A. Civil-time seconds are 12/13 s (i.e., 12/13 of an SI second, or about 0.923 s), so that civil-time minutes and hours are both 12/13 of their SI counterparts. B. Civil-time seconds are the same as before, but civil-time minutes are 60 * 12/13 s (i.e., about 55.38 s). C. Civil-time seconds and minutes are the same as before, but civil-time hours are 60 * 12/13 min (i.e., about 55.38 SI minutes). D. Civil-time minutes are 60 * sqrt(12/13) s (about 57.65 s), and civil-time hours are 60 * sqrt(12/13) civil-time minutes (i.e., about 57.65 civil-time minutes). Category II: Adjust day lengths so that all or most days contain 26 SI hours. Three possibilities here are: E. Civil-time days are 26 SI hours, and the calendar gradually falls further and further behind the Gregorian calendar. F. Civil-time days are 26 SI hours, but skip every 13th day so that days stay roughly synchronized with the Gregorian calendar. G. At the end of every day, move clocks backward two hours, from 24:00 to 22:00, so that timestamps from 22:00:00 through 23:59:59 repeat. Do this consistently for eleven days, thus moving clocks backward a total of 22 hours. On the twelfth day move clocks forward 22 hours instead, from 24:00 to 22:00 the next day. Repeat this cycle indefinitely. This way, eleven days out of thirteen contain 26 hours, and the next two days combined also contain 26 hours - 24 hours in the twelfth day and 2 hours in the thirteenth. Of these methods something like (G) would be the most compatible with computerized timekeeping, as (G) conforms to POSIX-1.202x Draft 4.1[4] whereas (A) through (F) do not. (G) avoids timestamps like 25:30; G's hours, minutes or seconds are all of the usual lengths; and (G) contains only transitions that are like daylight-saving transitions that computerized timekeeping can already deal with. Although a downside of (G) is that at times the sun will be at its zenith at midnight, I assume Vadsø residents are already accustomed to midnight suns so this disadvantage is relatively minor for them. Another downside of (G) is that clocks will never go "from 12 to 13" as the mayor requested, but given the major technical difficulties of (A) through (F) I hope the mayor would appreciate that (G) may be the best we can practically hope for in today's standardized and computerized world. Unfortunately even (G) would require some changes to tzcode and tzdata to become practical, and it would take many years for these changes to propagate to devices in common use in Vadsø. So, unless Vadsø residents are prepared to change their clocks by hand every day for the next several years, it does not appear that the mayor's proposal will be practical any time soon. I am sending this email to the time zone mailing list, as perhaps someone on the list can think of even better ways to implement the mayor's request. I am also cc'ing this email to Mayor Pedersen to give her a heads-up about this analysis, should it ever be needed in Vadsø. [1]: https://kommunikasjon.ntb.no/files/17848798/18066114/57109/no [2]: https://www.politico.eu/article/norway-arctic-region-asks-eu-commission-for… [3]: https://mm.icann.org/pipermail/tz/2019-June/028154.html [4]: https://www.opengroup.org/austin/

6 5

Kazakhstan Airline Schedules
by Owen Leibman April 14, 2024

April 14, 2024

I have a friend in Kazakhstan whom, thanks to this list, I notified about the recent time change before it was widely known in the country. She says the transition was pretty smooth, but, over a month later, sent me a message, which I pass on (without the attachments showing the discrepancies) as an anecdotal demonstration of how hard it is to get all the pieces in place: Happy eclipse day! I'm sending an update for your friends on time zones and flights. I booked a flight in February to Frankfurt leaving this Wednesday. United says the flight departs 4:20 a.m., but Lufthansa sent me an email saying I could check in for my flight which leaves at 3:20 a.m. Yet another Lufthansa check-in screen and the boarding pass says it leaves at 4:20. Meanwhile FlightAware claims the flight is not leaving till 5:20 a.m. All have the same arrival time of 9 a.m. Nursultan airport website does not list the flight yet. I will let you know which one proves to be right! I think it's 4:20. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.

2 3

[PROPOSED] Shanks is likely wrong about Maputo switch to CAT
by Paul Eggert April 9, 2024

April 9, 2024

* NEWS: Mention the change, and leave room for future Portugal fixes. * africa (Africa/Maputo): Tweak LMT to match London Gazette, and change CAT transition date to a guess of 1909. --- NEWS | 4 ++++ africa | 19 ++++++++++++++----- 2 files changed, 18 insertions(+), 5 deletions(-) diff --git a/NEWS b/NEWS index 25d939f1..0d6a1513 100644 --- a/NEWS +++ b/NEWS @@ -4,6 +4,7 @@ Unreleased, experimental changes Briefly: The main data form now uses %z. + Improve historical data for Portugal and possessions. Changes to data @@ -15,6 +16,9 @@ Unreleased, experimental changes the represented data: the generated TZif files are unchanged. Rearguard form still avoids %z, to support obsolescent parsers. + Some transitions for Portugal and possessions have been changed. + This affects timestamps for Africa/Maputo before 1909. + 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. Similarly, America/Scoresbysund diff --git a/africa b/africa index a731dbee..695d66ed 100644 --- a/africa +++ b/africa @@ -1101,13 +1101,22 @@ Zone Africa/El_Aaiun -0:52:48 - LMT 1934 Jan # El Aaiún # Zambia # Zimbabwe # -# Shanks gives 1903-03-01 for the transition to CAT. -# Perhaps the 1911-05-26 Portuguese decree -# https://dre.pt/pdf1sdip/1911/05/12500/23132313.pdf -# merely made it official? +# From Paul Eggert (2024-04-09): +# The London Gazette, 1903-04-03, page 2245, says that +# as of 1903-03-03 a time ball at the port of Lourenço Marques +# (as Maputo was then called) was dropped daily at 13:00:00 LMT, +# corresponding to 22:49:41.7 GMT; round this to UT+2:10:18. +# Conversely, the newspaper South Africa, 1909-02-09, page 321, +# says the port had just installed an apparatus that communicated +# "from the controlling clock in the new Observatory at Reuben Point ... +# exact mean South African time, i.e., 30 deg., or 2 hours East of Greenwich". +# Although Shanks gives 1903-03-01 for the transition to CAT, +# evidently the port transitioned to CAT after 1903-03-03 but before +# the Portuguese legal transition of 1912-01-01 (see Europe/Lisbon commentary). +# For lack of better info, list 1909 as the transition date. # # Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Africa/Maputo 2:10:20 - LMT 1903 Mar +Zone Africa/Maputo 2:10:18 - LMT 1909 2:00 - CAT # Namibia -- 2.44.0

1 0

Using %z in FORMAT column of 'europe' etc.
by Paul Eggert April 8, 2024

April 8, 2024

[This is a repost with minor updates of <https://mm.icann.org/pipermail/tz/2024-March/058790.html>. This repost is in a separate email thread, with a clearer "Subject:" line.] The recent glitches with %z-related lines in the Portugal data lead me to think that it's time to start using %z in the main format. For example, instead of this: > # Zone NAME STDOFF RULES FORMAT [UNTIL] > Zone Atlantic/Azores -1:42:40 - LMT 1884 # Ponta Delgada > -1:54:32 - HMT 1912 Jan 1 2:00u # Horta MT > -2:00 Port -02/-01 1942 Apr 25 22:00s > -2:00 Port +00 1942 Aug 15 22:00s > -2:00 Port -02/-01 1943 Apr 17 22:00s > -2:00 Port +00 1943 Aug 28 22:00s > -2:00 Port -02/-01 1944 Apr 22 22:00s > -2:00 Port +00 1944 Aug 26 22:00s > -2:00 Port -02/-01 1945 Apr 21 22:00s > -2:00 Port +00 1945 Aug 25 22:00s > -2:00 Port -02/-01 1966 Apr 3 2:00 > -1:00 Port -01/+00 1983 Sep 25 1:00s > -1:00 W-Eur -01/+00 1992 Sep 27 1:00s the 'europe' file should contain this: > # Zone NAME STDOFF RULES FORMAT [UNTIL] > Zone Atlantic/Azores -1:42:40 - LMT 1884 # Ponta Delgada > -1:54:32 - HMT 1912 Jan 1 2:00u # Horta MT > -2:00 Port %z 1966 Apr 3 2:00 > -1:00 Port %z 1983 Sep 25 1:00s > -1:00 W-Eur %z 1992 Sep 27 1:00s This would eventually simplify future maintenance and help avoid similar glitches in the future. For now, the 'rearguard' format would continue to avoid %z in the FORMAT column. It's reasonable to use %z in 'europe' now, as zic has supported %z since release 2015f.

1 1

[PROPOSED] Treat W-Eur like Port when reguarding
by Paul Eggert April 8, 2024

April 8, 2024

* ziguard.awk: When deciding among vanguard, main and rearguard forms, treat W-Eur lines like Port lines, since Portuguese zones use both. This should simplify future changes. --- ziguard.awk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ziguard.awk b/ziguard.awk index a5fd5491..066f3b10 100644 --- a/ziguard.awk +++ b/ziguard.awk @@ -142,7 +142,7 @@ DATAFORM != "main" { # If this line should differ due to Portugal benefiting from %z if supported, # uncomment the desired version and comment out the undesired one. - if ($0 ~ /^#?[\t ]+-[12]:00[\t ]+(Port[\t ]+[%+-]|-[\t ]+(%z|-01)[\t ]+1982 Mar 28)/) { + if ($0 ~ /^#?[\t ]+-[12]:00[\t ]+((Port|W-Eur)[\t ]+[%+-]|-[\t ]+(%z|-01)[\t ]+1982 Mar 28)/) { if (($0 ~ /%z/) == (DATAFORM == "vanguard")) { uncomment = in_comment } else { -- 2.40.1

1 0

Wrong symlinks with BACKWARD=backward PACKRATDATA=backzone
by Benjamin Drung April 8, 2024

April 8, 2024

Hi, the Debian/Ubuntu package uses BACKWARD=backward PACKRATDATA=backzone. The resulting tzdata.zi has the timezone Africa/Asmara, but Africa/Asmera points to Africa/Nairobi instead of the existing Africa/Asmara: ``` $ make AWK=gawk BACKWARD="backward" PACKRATDATA=backzone PACKRATLIST=zone.tab VERSION_DEPS= tzdata.zi gawk \ -v DATAFORM=`expr main.zi : '$.*$.zi'` \ -v PACKRATDATA='backzone' \ -v PACKRATLIST='zone.tab' \ -f ziguard.awk \ africa antarctica asia australasia europe northamerica southamerica etcetera factory backward backzone >main.zi.out mv main.zi.out main.zi { (type git) >/dev/null 2>&1 && \ V=`git describe --match '[0-9][0-9][0-9][0-9][a-z]*' \ --abbrev=7 --dirty` || \ if test 'unknown' = unknown && V=`cat version`; then \ case $V in *-dirty);; *) V=$V-dirty;; esac; \ else \ V='unknown'; \ fi; } && \ printf '%s\n' "$V" >version.out mv version.out version version=`sed 1q version` && \ LC_ALL=C gawk \ -v dataform='main' \ -v deps='ziguard.awk africa antarctica asia australasia europe northamerica southamerica etcetera factory backward backzone zone.tab zishrink.awk' \ -v redo='posix_right' \ -v version="$version" \ -f zishrink.awk \ main.zi >tzdata.zi.out mv tzdata.zi.out tzdata.zi $ grep Asmera tzdata.zi L Africa/Nairobi Africa/Asmera ``` Can this fixed/configured? -- Benjamin Drung Debian & Ubuntu Developer

3 10

[PATCH v2] tzfile.5: Fix indentation
by Alejandro Colomar April 8, 2024

April 8, 2024

RS after IP, if the indentation amount is not specified, takes the same indentation that IP had. The values being used were wrong, and by removing them, we're fixing the indentation of the page. Also, one RS was not just incorrect, but completely unnecessary, and there was a missing RE. Cc: "G. Branden Robinson" <branden(a)debian.org> Cc: Paul Eggert <eggert(a)cs.ucla.edu> Signed-off-by: Alejandro Colomar <alx(a)kernel.org> --- tzfile.5 | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tzfile.5 b/tzfile.5 index 867348d6..aa6b858d 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -42,7 +42,7 @@ .SH DESCRIPTION Fifteen bytes containing zeros reserved for future use. .IP \(bu Six four-byte integer values, in the following order: -.RS "\w' \(bu 'u" +.RS .TP "\w' 'u" .B tzh_ttisutcnt The number of UT/local indicators stored in the file. @@ -66,6 +66,7 @@ .SH DESCRIPTION The number of bytes of time zone abbreviation strings stored in the file. .RE +.RE .PP The above header is followed by the following fields, whose lengths depend on the contents of the header: @@ -134,8 +135,7 @@ .SH DESCRIPTION is in the range [\-89999, 93599] (i.e., more than \-25 hours and less than 26 hours); this allows easy support by implementations that already support the POSIX-required range [\-24:59:59, 25:59:59]. -.RS "\w' 'u" -.IP \(bu "\w'\(bu 'u" +.IP \(bu .B tzh_charcnt bytes that represent time zone designations, which are null-terminated byte strings, each indexed by the -- 2.43.0

4 24

Unearthly time zone in the news
by Arthur David Olson April 7, 2024

April 7, 2024

"Moon Standard Time? Nasa to create lunar-centric time reference system: Space agency tasked with establishing Coordinated Lunar Time, partly to aid missions requiring extreme precision" Not to be missed: the opportunity to have neap seconds. @dashdashado https://www.theguardian.com/science/2024/apr/02/moon-nasa-coordinated-lunar…

7 8

[PROPOSED] America/Scoresbysund matches America/Nuuk from now on
by Paul Eggert April 3, 2024

April 3, 2024

This pacifies ‘make check_now’. * NEWS: Mention this. * zonenow.tab: Remove America/Scoresbysund. --- NEWS | 4 +++- zonenow.tab | 2 -- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index 8efa195f..54dcd21b 100644 --- a/NEWS +++ b/NEWS @@ -6,7 +6,9 @@ Unreleased, experimental changes 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. + 2024-02-29 time zone change. Similarly, America/Scoresbysund + has been removed, as it how agrees with America/Nuuk due to + its 2024-03-31 time zone change. Release 2024a - 2024-02-01 09:28:56 -0800 diff --git a/zonenow.tab b/zonenow.tab index 1e7a86be..84f27e93 100644 --- a/zonenow.tab +++ b/zonenow.tab @@ -123,8 +123,6 @@ XX +1455-02331 Atlantic/Cape_Verde Cape Verde # # -01/+00 (EU DST) XX +3744-02540 Atlantic/Azores Azores -# -01/+00 (EU DST) until 2024-03-31; then -02/-01 (EU DST) -XX +7029-02158 America/Scoresbysund Ittoqqortoormiit # # +00 - GMT XX +0519-00402 Africa/Abidjan far western Africa; Iceland ("GMT") -- 2.40.1

2 2

vzic link in tz-link.html
by Allen Winter March 28, 2024

March 28, 2024

Hi, I'm the current maintainer of vzic. We moved the project from sourceforge to github many years ago and I've been informed that your tz-link.html page still points to the old sourceforge url. Please update tz-link.html so that the vzic link points to https://github.com/libical/vzic

2 1

Negative leap second in main stream media.
by Arthur David Olson March 28, 2024

March 28, 2024

'...although the core is causing the planet to spin faster, the planetary shape changes caused by a warming climate are slowing that process. Absent this effect...the overall acceleration of the planet’s rotation might require timekeepers to insert a “negative leap second” at the end of 2026. Because of climate change, that might not be necessary until 2029.' "Climate change is altering Earth’s rotation enough to mess with our clocks," Washington Post, 2024-03-28. Behind a paywall: https://www.washingtonpost.com/science/2024/03/27/leap-second-melting-poles… @dashdashado

3 2

Asia/Tehran +3:30
by Mohammad Farshad March 28, 2024

March 28, 2024

Dear Sir/Madam I think the time zone of Theran/Iran is not correct in the 2024a version. "After returning to the standard time on 22 September 2022, the Iran Government elected to remain permanently in the standard time, cancelling daylight saving time. Hence, Iran will permanently remain at UTC + 3:30 time zone going forward." Link: Iran 2023 time zone update now available - Microsoft Community Hub <https://techcommunity.microsoft.com/t5/daylight-saving-time-time-zone/iran-….> Best regards, Mohammad farshad

3 3

Re: [tz] Asia/Tehran +3:30
by brian.inglis＠systematicsw.ab.ca March 27, 2024

March 27, 2024

On 2024-03-26 14:49, Tim Parenti via tz wrote: > On Tue, 26 Mar 2024 at 15:00, Mohammad Farshad via tz wrote: >> I think the time zone of Theran/Iran is not correct in the 2024a version. > Our data has Iran on UTC+3:30 year-round from 2023 onward. If this is > incorrect, please point us to official announcements that indicate otherwise. > Alternatively, if you believe you're seeing incorrect timestamps for Iran > generated by 2024a, please provide more detail on the precise behavior > you're observing and the system you're running on. >> "After returning to the standard time on 22 September 2022, the Iran >> Government elected to remain permanently in the standard time, cancelling >> daylight saving time. Hence, Iran will permanently remain at UTC + 3:30 time >> zone going forward." > Note that our Iran DST rules stop after 2022. This change was made on > 2022-05-10 and released in version 2022b on 2022-08-10: > <https://github.com/eggert/tz/commit/66b18d9835dda089d65349c86e7851c4f0746e09> $ head /usr/share/doc/tzdata/version 2024a # Last transitions: $ zdump -Vc2022,2025 Asia/Tehran Asia/Tehran Mon Mar 21 20:29:59 2022 UT = Mon Mar 21 23:59:59 2022 +0330 isdst=0 gmtoff=12600 Asia/Tehran Mon Mar 21 20:30:00 2022 UT = Tue Mar 22 01:00:00 2022 +0430 isdst=1 gmtoff=16200 Asia/Tehran Wed Sep 21 19:29:59 2022 UT = Wed Sep 21 23:59:59 2022 +0430 isdst=1 gmtoff=16200 Asia/Tehran Wed Sep 21 19:30:00 2022 UT = Wed Sep 21 23:00:00 2022 +0330 isdst=0 gmtoff=12600 Not every system uses tzdata, nor keeps it up to date, and some systems take longer to get changes into production releases. We are aware of the sometimes months long update, test, release pipeline delays with Apple, Oracle (and Java), and other vendor tzdata updates. MS just announced in their DST blog "interim" guidance on: - 2021 Samoa stopping DST will be in Windows 2024 March preview or April security updates; and previously for - 2022 October Syria stopping DST a year later in 2023 October/November Windows updates! https://techcommunity.microsoft.com/t5/daylight-saving-time-time-zone/inter… https://techcommunity.microsoft.com/t5/daylight-saving-time-time-zone/inter… The "interim" normally means guidance issued shortly after the government announcement, before the MS Windows update; *not* long after the announcement, and just before they finally figured out how to make the ridiculously delayed updates! I wonder how they do with .NET (uses tzdata), Outlook, Exchange, MS-SQL? -- 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

1 0

mktime() clarification
by Dag-Erling Smørgrav March 26, 2024

March 26, 2024

Both the C standard and POSIX state that mktime() returns -1 on failure; POSIX additionally states that it sets errno. However, since -1 is also a valid result (representing 23:59:59 UTC on 1969-12-31) and POSIX never guarantees that a successful call does not modify errno, it seems to me that the only reliable way to determine whether mktime() succeeded, within the bounds of the aforementioned standards, is to set tm_wday or tm_yday to an out-of-bounds value (e.g. -1) prior to calling mktime() and check whether it has been modified on return. As far as I can tell, this has been the case ever since mktime() was introduced in POSIX.1 in 1988 and XPG3 and ANSI C in 1989. Am I wrong? Would it be a mistake to state this outright in the appropriate manual page? DES -- Dag-Erling Smørgrav - des(a)des.no

6 14

TZ Environment Variable in Australia/Lord_Howe
by Bill Seymour March 20, 2024

March 20, 2024

I notice in Australia/Lord_Howe that the TZ environment variable in the compiled TZif file is: <+1030>-10:30<+11>-11,M10.1.0,M4.1.0 Are the signs backwards, i.e., should the signs between the angle brackets be the wrong ones and the offsets after the '>' be the right ones? The Zone record in the 2024a release is: Zone Australia/Lord_Howe 10:36:20 - LMT 1895 Feb 10:00 - AEST 1981 Mar 10:30 LH +1030/+1130 1985 Jul 10:30 LH +1030/+11 --Bill Seymour

2 1

Ubuntu drops old-style links
by Matt Johnson-Pint March 19, 2024

March 19, 2024

I just learned that Ubuntu Noble (24.04) decided to intentionally split the tzdata package. Old-style links such as US/Eastern are no longer included by default, but are available in the tzdata-legacy package instead. Just thought I'd share. I wonder if other distributions / platforms / libraries will follow suit. What do y'all think? See: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2058249 https://stackoverflow.com/questions/78180695/unrecognized-time-zone -Matt

2 1

troff(1) warning on zic(8)
by Alejandro Colomar March 17, 2024

March 17, 2024

Hi Paul, I've been looking at tz.git to fix some indentation issues, and saw this warning in one page: $ man ./zic.8 troff:<standard input>:357: warning: unbalanced 'el' request $ type man man is a function man () { if command man "$@"; then command man --warnings=w "$@" > /dev/null; fi } Have a lovely day! Alex -- <https://www.alejandro-colomar.es/>

2 1

[PATCH] tzfile.5: Fix indentation
by Alejandro Colomar March 17, 2024

March 17, 2024

RS after IP, if the indentation amount is not specified, takes the same indentation that IP had. The values being used were wrong, and by removing them, we're fixing the indentation of the page. Cc: "G. Branden Robinson" <branden(a)debian.org> Cc: Paul Eggert <eggert(a)cs.ucla.edu> Signed-off-by: Alejandro Colomar <alx(a)kernel.org> --- tzfile.5 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tzfile.5 b/tzfile.5 index 867348d6..ef0c14e6 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -42,7 +42,7 @@ .SH DESCRIPTION Fifteen bytes containing zeros reserved for future use. .IP \(bu Six four-byte integer values, in the following order: -.RS "\w' \(bu 'u" +.RS .TP "\w' 'u" .B tzh_ttisutcnt The number of UT/local indicators stored in the file. @@ -134,7 +134,7 @@ .SH DESCRIPTION is in the range [\-89999, 93599] (i.e., more than \-25 hours and less than 26 hours); this allows easy support by implementations that already support the POSIX-required range [\-24:59:59, 25:59:59]. -.RS "\w' 'u" +.RS .IP \(bu "\w'\(bu 'u" .B tzh_charcnt bytes that represent time zone designations, -- 2.43.0

1 1

Bug#1067022: man2html: Segmentation fault with tzfile(5)
by Alejandro Colomar March 16, 2024

March 16, 2024

Package: man2html Version: 1.6g-16 Severity: normal Tags: upstream X-Debbugs-Cc: Alejandro Colomar <alx(a)kernel.org>, Paul Eggert <eggert(a)cs.ucla.edu>, "G. Branden Robinson" <branden(a)debian.org>, linux-man(a)vger.kernel.org, groff(a)gnu.org, tz(a)iana.org Dear Maintainer, The page tzfile(5) from tzdb-2024a manages to consistently produce a Segmentation fault with man2html(1). Below is a reproducer: alx@debian:~/tmp$ wget https://data.iana.org/time-zones/releases/tzdb-2024a.tar.lz 2>/dev/null alx@debian:~/tmp$ tar xf tzdb-2024a.tar.lz alx@debian:~/tmp$ man2html tzdb-2024a/tzfile.5 Content-type: text/html; charset=UTF-8 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML><HEAD><TITLE>Man page of tzfile</TITLE> </HEAD><BODY> <H1>tzfile</H1> Section: File Formats (5)<BR>Updated: <BR><A HREF="#index">Index</A> <A HREF="/cgi-bin/man/man2html">Return to Main Contents</A><HR> <A NAME="lbAB"> </A> <H2>NAME</H2> tzfile - timezone information <A NAME="lbAC"> </A> <H2>DESCRIPTION</H2> The timezone information files used by <B><A HREF="/cgi-bin/man/man2html?3+tzset">tzset</A></B>(3) are typically found under a directory with a name like <I>/usr/share/zoneinfo</I>. These files use the format described in Internet RFC 8536. Each file is a sequence of 8-bit bytes. In a file, a binary integer is represented by a sequence of one or more bytes in network order (bigendian, or high-order byte first), with all bits significant, a signed binary integer is represented using two's complement, and a boolean is represented by a one-byte binary integer that is either 0 (false) or 1 (true). The format begins with a 44-byte header containing the following fields: Segmentation fault alx@debian:~/tmp$ dpkg -l | grep man2html ii man2html 1.6g-16 amd64 browse man pages in your web browser ii man2html-base 1.6g-16 amd64 convert man pages into HTML format I've refreshed this page today, and the previous version I used didn't have this crash. Below is the part of the diff that I think is responsible for the crash: diff --git a/man5/tzfile.5 b/man5/tzfile.5 index 45afecc10..867348d67 100644 --- a/man5/tzfile.5 +++ b/man5/tzfile.5 @@ -26,23 +26,24 @@ .SH DESCRIPTION and a boolean is represented by a one-byte binary integer that is either 0 (false) or 1 (true). The format begins with a 44-byte header containing the following fields: -.IP * 2 +.RS "\w' 'u" +.IP \(bu "\w'\(bu 'u" The magic four-byte ASCII sequence .q "TZif" identifies the file as a timezone information file. BTW, I noticed that the upstream homepage is dead: <http://users.actrix.gen.nz/michael/vhman2html.html>. Is this project defunct? Have a lovely day! Alex -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.8.0-rc7-alx-dirty (SMP w/24 CPU threads; PREEMPT) Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages man2html depends on: ii debconf [debconf-2.0] 1.5.86 ii gawk 1:5.2.1-2 ii libc6 2.37-15.1 ii lynx 2.9.0rel.0-2+b1 ii man-db 2.12.0-3 ii man2html-base 1.6g-16 ii sensible-utils 0.0.22 man2html recommends no packages. Versions of packages man2html suggests: ii firefox-esr [www-browser] 115.8.0esr-1+b1 ii lynx [www-browser] 2.9.0rel.0-2+b1 pn swish++ <none> ii w3m [www-browser] 0.5.3+git20230121-2+b3 -- debconf information: man2html/index_manpages: true

1 0

People Hate Daylight Saving. Science Tells Us Why.
by Brian Inglis March 14, 2024

March 14, 2024

A summary of various studies and opinions: https://undark.org/2024/03/11/time-zones-daylight-saving/ -- 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

1 0