February 2024 - tz - lists.iana.org

(no subject)
by Cool Gab19 05 Sep '24

05 Sep '24

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 7

Re: [tz] Time for a Lunar time zone? -Brooks
by Paul Eggert 11 Jul '24

11 Jul '24

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 01 Jul '24

01 Jul '24

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

Happy Leap Day...
by Arthur David Olson 01 Mar '24

01 Mar '24

...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 01 Mar '24

01 Mar '24

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

Administrivia: Mailing List Archives
by Kim Davies 25 Feb '24

25 Feb '24

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 19 Feb '24

19 Feb '24

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 18 Feb '24

18 Feb '24

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

Checked arithmetic bug
by Dag-Erling Smørgrav 16 Feb '24

16 Feb '24

In at least one instance around line 1187 of localtime.c, the code assumes that increment_overflow_time() does not modify the result if the operation overflowed, but that is not true when using C23 checked arithmetic. Details: https://bugs.freebsd.org/276281, particularly comment 11. One possible solution is attached. I'm not overly fond of it because it penalizes the common case, but it was easier than trying to understand and reformulate the loop in tzparse(). DES -- Dag-Erling Smørgrav - des(a)des.no

2 1

the Republic of Kazakhstan
by ЕЛИКБАЕВ КУАНЫШ НУРЛАНОВИЧ 05 Feb '24

05 Feb '24

Dear colleagues, Technical Regulation and Metrology Committee of the Ministry of Trade and Integration of the Republic of Kazakhstan (CTRM) takes this opportunity to express its assurances of the highest consideration. CTRM participates in the implementation of strategic functions of the Ministry in the areas of technical regulation and Metrology. CTRM informs that by the Decree of the Government of the Republic of Kazakhstan dated January 19, 2024 No. 20, amendments have been made to the Decree of the Government of the Republic of Kazakhstan dated November 23, 2000 No. 1749 «On the procedure for calculating time on the territory of the Republic of Kazakhstan» (https://zan.gov.kz/client/#!/doc/192700/rus) which provides, among other things, for the Akimats of the cities of Astana, Almaty, Shymkent, Akmola, Almaty, Zhambyl, Karaganda, Kostanay, Pavlodar, North Kazakhstan, Turkestan, East Kazakhstan regions and Abay, Zhetisu, Ulytau regions, on the night of February 29, 2024 to March 1, 2024 (Astana time, 12:00 a.m.), to transfer local time back 1 hour Information that the Republic of Kazakhstan is switching to Single Time Zone (UTC+05:00) is sent for accounting in work when interacting with government agencies and organizations of the Republic of Kazakhstan. Please find the attached letter. Sincerely, Mr. Kuanysh Yelikbayev Chairman

2 1