March 2024 - tz - lists.iana.org

(no subject)
by Cool Gab19 Nov. 8, 2024

Nov. 8, 2024

can you add Philippine Daylight Time on your Database I think it was missing from the list of the time zones please reply immediately if solved thanks...

4 8

Re: [tz] Time for a Lunar time zone? -Brooks
by Paul Eggert July 11, 2024

July 11, 2024

On 3/2/23 09:51, Brooks Harris wrote: > Will we need DST on the Moon? :-) I hope not! The Moon's axis tilts only 1.5°, much less than the 23.5° of Earth's axis, so seasonal effects on sunlight duration are much less intense on the Moon and there should be less need for Earth-like DST. A more pressing issue is that the length of day (including daytime and nighttime) varies more on the Moon. Local Earth days vary by at most 0.008 hours from the mean of 24 hours (this variation is due to the eccentricity of the Earth orbit and the obliquity of the ecliptic). So people who think that every local Earth day is exactly 24 hours are not far off. Local lunar days, in contrast, are roughly 29.5 ± 0.25 Earth days (again, this includes both lunar daytime and lunar nighttime). That's more slop to deal with, relatively speaking, and dealing with varying-length days could be a bit of a problem for civil time on the Moon. Presumably ESA's boffins are on top of this.....

4 5

error Portugal 1980
by Alois Treindl July 2, 2024

July 2, 2024

I think there is an error in TZ, regarding begin of DST in Portugal in 1980. A user of my website pointed it out. file europe has > Rule Port 1978 only - Oct 1 0:00s 0 - > Rule Port 1979 1982 - Sep lastSun 1:00s 0 - > Rule Port 1980 only - Mar lastSun 0:00s 1:00 S > Rule Port 1981 1982 - Mar lastSun 1:00s 1:00 S > Rule Port 1983 only - Mar lastSun 2:00s 1:00 S But Observatório Astronómico de Lisboa http://oal.ul.pt/hora-legal/legislacao-sobre-a-hora-legal/ has in document Tabela com a definição anual da Hora Legal portuguesa desde 1911 https://oal.ul.pt/documentos/2018/01/hl1911a2018.pdf > 1980 Hora do meridiano de Greenwich até à 1 hora do dia 6 de Abril, > instante > em que foi adiantada de 60 minutos, tendo-se regressado à hiora do meri- > diano de Greenwich às 2 horas do dia 28 de Setembro (Portaria nº 69/80) > I attach a patch file

4 12

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

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

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

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

March 13, 2024

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

3 2

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

March 11, 2024

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

1 0

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

March 10, 2024

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

1 0

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

March 9, 2024

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

6 18

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

March 8, 2024

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

7 7

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

March 5, 2024

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

3 2

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

March 3, 2024

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

2 1

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

March 1, 2024

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

4 3