- tz - lists.iana.org

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