- tz - lists.iana.org

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 6, 2024

March 6, 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 4, 2024

March 4, 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

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