August 2024 - tz - lists.iana.org

(no subject)
by Cool Gab19 07 Nov '24

07 Nov '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 8

Ukraine to abolish DST?
by Steffen Thorsen 26 Oct '24

26 Oct '24

Ukraine seems to be getting rid of DST, according to https://universemagazine.com/en/the-verkhovna-rada-canceled-daylight-saving… "During a meeting of the Verkhovna Rada of Ukraine on June 16, daylight saving time was canceled. According to MP Yaroslav Zheleznyak, 261 MPs voted in favor of the bill. Now it must be signed by the President of Ukraine, and then it will come into force." which is again referencing (in Ukrainan) https://lb.ua/society/2024/07/16/624453_verhovna_rada_skasuvala_perehid.html It seems they will plan to set back time this autumn to winter(standard) time, and then stay on that. Best regards, Steffen Thorsen - timeanddate.com

5 8

Mailman Upgrade Announcement
by David Dong 27 Aug '24

27 Aug '24

Hello, Over the coming days the infrastructure behind this mailing list will be upgraded. IANA hosts a number of operational mailing lists using ICANN's mailing list infrastructure. This infrastructure is currently undergoing a major upgrade, including to the mailman software that operates this list. Users should not observe a difference except for modernization of the mailing list administration website. Mailing list archives will move to a new archiver, but old archives will be retained to preserve references to archived messages. The archives may be delayed by several hours during the migration. We will send an announcement following the migration that will also serve as a confirmation of the operational status of the mailing list and will provide a link to the new archives. If you have problems caused by the migration, please contact the IANA team at iana(a)iana.org so we may help remedy them. Best regards, David Dong IANA Services Sr. Specialist

4 6

FW: Europe/Dublin
by josephcaggiano＠ups.com 21 Aug '24

21 Aug '24

From: Joseph Caggiano Sent: Tuesday, August 20, 2024 3:05 PM To: tz(a)iana.org Cc: Douglas Weichert <dweichert(a)ups.com>; Autumn McPhillips <amcphillips(a)ups.com>; Matt Taylor <mxtaylor(a)ups.com>; Vinothkumar Vamanan <vinothkumarvamanan(a)ups.com> Subject: Europe/Dublin Hello, Our team has an application on a monthly basis which downloads the latest time zone tar file from IANA.org and processes the files to load tables with the time zones and rule information. We were recently informed our offset information for Europe/Dublin was incorrect. Based upon our team's analysis of this zone and rule, it appears the zone may be assigned to an incorrect rule (Eire). A similar zone, Europe/London, is assigned to the EU rule. [cid:image001.png@01DAF310.A356C510] Please advise if this information is accurate and if not, can it be updated. Thank you. Joe Caggiano Lead Data Engineer - CRD 201-828-2303 josephcaggiano(a)ups.com<mailto:josephcaggiano@ups.com>

3 2

Request to Include DateTimeOnline in "Time Zone and Daylight Saving Time Data" Page
by Santosh Sahu 21 Aug '24

21 Aug '24

Dear TZ team, I hope you are doing well. Over the past two years, with considerable effort and dedication, I have developed a website called DateTimeOnline<https://www.datetimeonline.com/>. This platform provides comprehensive information on date, time, time zones, and daylight-saving time for over 35,000 locations worldwide. Additionally, it offers weather details for these places and includes a time zone converter<https://www.datetimeonline.com/time_zone_converter.php>, allowing users to compare the time between two locations quickly. If you find it valuable, I would be honoured if you consider including a link to DateTimeOnline<https://www.datetimeonline.com/> <https://www.datetimeonline.com/> in your website's "Time Zone and Daylight Saving Time Data<https://web.cs.ucla.edu/~eggert/tz/tz-link.html>" page. Thank you for your time and consideration. Best regards, Santosh Sahu santosh.sahu(a)datetimeonline.com<mailto:santosh.sahu@datetimeonline.com> [cid:730d3fc6-203f-46b0-94fd-892fd353e141]

1 0

Past changes in Mexico
by Heitor David Pinto 20 Aug '24

20 Aug '24

Hello, I'd like to suggest several corrections to past time changes in Mexico. In 1931, the decree implementing DST specified that it would take effect on 30 April, so I suppose that DST started on that date at 0:00. The database currently says 1 May at 23:00. https://www.dof.gob.mx/nota_to_imagen_fs.php?cod_diario=192270&pagina=2&sec… In 1981, the decree changing Campeche, Yucatán and Quintana Roo to UTC-5 specified that it would enter into force on 26 December 1981 at 2:00. The database currently says 23 December 1981, which was the date of publication of the decree. https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4705667&fecha=23/12/19… In 1982, the decree returning Campeche and Yucatán to UTC-6 specified that it would enter into force on 2 November 1982 at 2:00. The database currently says 2 December 1982. https://www.dof.gob.mx/nota_to_imagen_fs.php?cod_diario=205689&pagina=3&sec… Quintana Roo changed to UTC-6 on 4 January 1983 at 0:00, and again to UTC-5 on 26 October 1997 at 2:00. These changes are not currently included in the database. https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4787355&fecha=28/12/19… https://www.dof.gob.mx/nota_to_imagen_fs.php?cod_diario=209559&pagina=15&se… Durango, Coahuila, Nuevo León and Tamaulipas were set to UTC-7 on 1 January 1922, and changed to UTC-6 on 10 June 1927. Then Durango, Coahuila and Nuevo León (but not Tamaulipas) returned to UTC-7 on 15 November 1930, observed DST in 1931, and changed again to UTC-6 on 1 April 1932. The database currently shows all these states set to UTC-6 on 1 January 1922. https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4441846&fecha=29/12/19… https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4541520&fecha=09/06/19… https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4491963&fecha=15/11/19… https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4418437&fecha=21/01/19… The database currently shows the time change of 10 June 1927 occurring at 23:00 in all time zones that have such change. However, the decree only said 10 June 1927, without specifying a time, so I suppose that it should be considered at 0:00. https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4541520&fecha=09/06/19… In 1942, the decree changing Baja California, Baja California Sur, Sonora, Sinaloa and Nayarit to UTC-7 was published on 24 April, but it said that it would apply from 1 April, so it's unclear when the change actually occurred. The database currently shows 24 April 1942. https://www.dof.gob.mx/nota_to_imagen_fs.php?cod_diario=192203&pagina=2&sec… Baja California Sur, Sonora, Sinaloa and Nayarit never used UTC-8. The database shows these states changing to UTC-8 on 14 January 1949, but this change only occured in Baja California. https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4515613&fecha=13/01/19… In 1945, the decree changing Baja California to UTC-8 specified that it would take effect on the third day from its publication. It was published on 12 November, so it would take effect on 15 November. The database currently says 12 November 1945. https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4555049&fecha=12/11/19… In 1948, the decree changing Baja California to UTC-7 specified that it would take effect on "this date". The decree was made on 13 March, but published on 5 April, so it's unclear when the change actually occurred. The database currently shows 5 April 1948. https://www.dof.gob.mx/nota_to_imagen_fs.php?cod_diario=188624&pagina=2&sec… In 1949, the decree changing Baja California to UTC-8 was published on 13 January, but it said that it would apply from 1 January, so it's unclear when the change actually occurred. The database currently shows 14 January 1949. https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4515613&fecha=13/01/19… Baja California also observed UTC-7 from 1 May to 24 September 1950, from 29 April to 30 September 1951 at 2:00, and from 27 April to 28 September 1952 at 2:00. These changes are not currently included in the database. https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4600403&fecha=29/04/19… https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4623553&fecha=23/09/19… https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4469444&fecha=27/04/19… https://www.dof.gob.mx/nota_to_imagen_fs.php?codnota=4533868&fecha=10/03/19… All changes in Baja California from 1948 to 1952 match those in California, on the same dates or with a difference of one day. So it may be easier to implement these changes as DST with rule CA during this whole period. Regards, David

2 2

Re: Ukraine to abolish DST?
by Yuriy Novostavskiy 16 Aug '24

16 Aug '24

+ CC On Fri, Aug 16, 2024 at 6:19 PM Yuriy Novostavskiy <yuriy(a)novostavskiy.kiev.ua> wrote: > > Hi Paul, > > This small update is just a heartbeat that has no updates so far, but > it's on my eye and I will update you when something changes. > > To fully clarify what the current status is and the expected next steps: > Parliament voted for https://itd.rada.gov.ua/billInfo/Bills/Card/4294 > and document reached required amount of votes, but to become a bill > this document should be signed by the President has not happened yet, > moreover, it has not even been signed by the Chairman of the Parlament > which is just a bureaucracy formality, but without that step, the > document will not be given to President for signature.It's quite an > unusual delay in the processing of bills. The whole story of that > document is quite long, it appeared back in 2020 and was just added to > the vote list in 2024. > > Another document that you mentioned > https://itd.rada.gov.ua/billInfo/Bills/Card/44572, it's a project of > the decision to reject the first one, but it's not even planned to > vote in the Parlament. > > So, stay tuned. > > On Thu, Jul 18, 2024 at 11:09 AM Yuriy Novostavskiy > <yuriy(a)novostavskiy.kiev.ua> wrote: > > > > I assumed that changes would technically take affects on March 30, > > 2025, when DST will not be introduced. Anyway, I propose to keep those > > changes in "work in progress" status until a new law is finally signed > > and published, and in the final text will have clear understanding of > > 'de jure' cut-off date. > > > > I will keep it tracked and will inform you. > > > > BR/Yurii > > > > On Wed, Jul 17, 2024 at 10:20 PM Paul Eggert <eggert(a)cs.ucla.edu> wrote: > > > > > > Thanks for the heads-up about the bill. I found a copy on the Rada > > > website[1]. Assuming the president signs it and it becomes law, we'll > > > need a change and a new TZDB release. > > > > > > The bill says that the law would take effect three months after > > > promulgation, so it'd be helpful to find out its promulgation date > > > whenever that happens to be. > > > > > > A further proposed resolution was introduced today[2] to annul > > > yesterday's decision and stick with the status quo, on the grounds that > > > yesterday's decision wasn't properly conducted. Not knowing Ukrainian > > > politics, I don't know how today's proposal will affect matters. > > > > > > I am attaching a draft TZDB patch but I haven't installed it into the > > > development version, because the effective date isn't known (I > > > approximated it as "2025" in the draft patch), the bill as it stands > > > might not become law, and the patch will need commentary. The > > > zonenow.tab part of the draft patch would be temporary and that file > > > would need to be updated further after 2024-10-27 as Ukraine would merge > > > with Libya and Kaliningrad for future timestamps. > > > > > > [1]: https://itd.rada.gov.ua/billInfo/Bills/Card/4294 > > > [2]: https://itd.rada.gov.ua/billInfo/Bills/Card/44572

1 0

netherland timezone UTC offset (0:19:32.13) history
by Eitan Adler 06 Aug '24

06 Aug '24

(I am not currently subscribed, please keep me CCed) Hi all, I'm interested in some specific timezone history. Specifically I'm curious about the origin of 'STDOFF 0:19:32.13'. Does anyone have an authoritative source for where this is derived from? Below is what I found so far: 1. In "NEWS" there is this entry: === zic now accepts subsecond precision in expressions like 00:19:32.13, which is approximately the legal time of the Netherlands from 1835 to 1937... === 2. Wikipedia here https://en.wikipedia.org/wiki/UTC%2B00:20 says === The reason for the specific offset of +0h 19m 32.13s was that the time zone was centered on the mean solar time of the Westertoren (4° 53' 01.95" E Longitude), the tower of the Westerkerk church in Amsterdam. === but I can't find any reference to this specific offset in any of the sources listed on Wikipedia. It is possible I missed the reference though. https://articles.adsabs.harvard.edu/pdf/1909Obs....32..297. https://books.google.com/books?id=MbA-AQAAIAAJ&pg=PA75&printsec=frontcover&… 3. I've seen several references that cite *to* wikipedia or tzdata, but I haven't been able to find anything older. (if this is off topic for the mailing list I apologize, this is the best place I could find) -- Eitan Adler

4 4

localized date without time
by Alejandro Colomar 01 Aug '24

01 Aug '24

Hi Paul, Link: <https://github.com/shadow-maint/shadow/issues/1057> Currently, shadow utils' passwd(1) (and several other programs) uses UTC time when printing. That is: $ passwd -S alx alx P 2023-09-20 0 99999 7 -1 the date from above is a UTC representation of $ sudo cat /etc/shadow | grep alx | cut -f3 -d: 19620 However, shadow utils programs, such as chage(1), use local time in input. That timestamp was set by chage(1), interpreting a local date: $ sudo chage -d 2023-09-21 alx $ sudo cat /etc/shadow | grep alx | cut -f3 -d: 19620 $ date Wed Jul 31 07:54:17 CEST 2024 This is rather confusing, and we think that passwd(1) should also print the date in local time, when printing human-readable dates. However, I think it might be better to show the timezone information together with the date, to be clear that what we're printing is local time. Do you think that's reasonable? Or maybe it's understood that when printing a date some timezone information is implicitly local? I didn't find any way to print timezone information in ISO 8601, if you don't print the time together with the date. That is, ISO 8601 says: C.1.3.1 Date A date string represents one of the following: • year, month, and day (e.g. 2001-02-03) • year and month (e.g. 2008-12 ) • year (e.g. 2008) and C.1.3.2 Date and Time A date/time string is composed according to one of three representations as illustrated in the following three examples: • 2001-02-03T09:30:01 • 2004-01-01T10:10:10Z • 2004-01-01T10:10:10+05:00 but I don't see any way to print something like 2023-09-21+02:00 in standardese. Is this a defect in ISO 8691? I see that in C.1.3.2, it says "Zone-offset may be omitted or included", so I guess we can just omit it. What do you think we should do? Thanks! And have a lovely day! Alex -- <https://www.alejandro-colomar.es/>

4 5

[PROPOSED] Mention Internet RFC 9557
by Paul Eggert 31 Jul '24

31 Jul '24

--- theory.html | 5 +++++ tz-link.html | 20 ++++++++++++-------- 2 files changed, 17 insertions(+), 8 deletions(-) diff --git a/theory.html b/theory.html index 10281af1..d3573ede 100644 --- a/theory.html +++ b/theory.html @@ -581,6 +581,11 @@ in decreasing order of importance: some sense undefined; this notation is derived from <a href="https://datatracker.ietf.org/doc/html/rfc3339">Internet <abbr title="Request For Comments">RFC</abbr> 3339</a>. + (The abbreviation 'Z' that + <a href="https://datatracker.ietf.org/doc/html/rfc9557">Internet + <abbr>RFC</abbr> 9557</a> uses for this concept + would violate the POSIX requirement + of at least three characters in an abbreviation.) </li> </ul> diff --git a/tz-link.html b/tz-link.html index 739d07af..4d883883 100644 --- a/tz-link.html +++ b/tz-link.html @@ -193,9 +193,10 @@ After obtaining the code and data files, see the <code>README</code> file for what to do next. The code lets you compile the <code><abbr>tz</abbr></code> source files into machine-readable binary files, one for each location. The binary files -are in a special timezone information format (<dfn><abbr>TZif</abbr></dfn>) -specified by <a href="https://datatracker.ietf.org/doc/html/8536">Internet -<abbr>RFC</abbr> 8536</a>. +are in a special format specified by +<a href="https://datatracker.ietf.org/doc/html/8536">The +Time Zone Information Format (<abbr>TZif</abbr>)</a> +(Internet <abbr title="Request For Comments">RFC</abbr> 8536). The code also lets you read a <abbr>TZif</abbr> file and interpret timestamps for that location.</p> @@ -262,8 +263,8 @@ Studio Code</a>. <p> For further information about updates, please see <a href="https://datatracker.ietf.org/doc/html/rfc6557">Procedures for -Maintaining the Time Zone Database</a> (Internet <abbr -title="Request For Comments">RFC</abbr> 6557). More detail can be +Maintaining the Time Zone Database</a> (Internet <abbr>RFC</abbr> 6557). +More detail can be found in <a href="theory.html">Theory and pragmatics of the <code><abbr>tz</abbr></code> code and data</a>. <a href="https://a0.github.io/a0-tzmigration/">A0 TimeZone Migration</a> @@ -1174,9 +1175,12 @@ headers.</li> <li> <a href="https://datatracker.ietf.org/doc/html/rfc3339">Date and Time on the Internet: Timestamps</a> (Internet <abbr>RFC</abbr> 3339) -specifies an <abbr>ISO</abbr> 8601 -profile for use in new Internet -protocols.</li> +specifies an <abbr>ISO</abbr> 8601 profile for use in new Internet protocols. +An extension, <a href="https://datatracker.ietf.org/doc/html/rfc9557">Date +and Time on the Internet: Timestamps with Additional Information</a> +(Internet <abbr>RFC</abbr> 9557) extends this profile +to let you specify the <code><abbr>tzdb</abbr></code> timezone of a timestamp +via suffixes like "<code>[Asia/Tokyo]</code>". <li> <a href="https://web.archive.org/web/20190130042457/https://www.hackcraft.net/web/da…">Date & Time Formats on the Web</a> surveys web- and Internet-oriented date and time -- 2.43.0

1 0