- tz - lists.iana.org

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

March 13, 2024

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

3 2

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

March 11, 2024

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

1 0

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

March 10, 2024

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

1 0

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

March 9, 2024

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

6 18

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

March 8, 2024

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

7 7

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

March 5, 2024

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

3 2

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

March 3, 2024

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

2 1

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

March 1, 2024

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

4 3

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

March 1, 2024

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

7 9

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

March 1, 2024

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

1 0