March 2024 - tz - lists.iana.org

Time Zone Database
by EL MAAYATI Afaf July 8, 2026

July 8, 2026

Dear Paul, I'm Afaf EL MAAYATI from National Telecommunications Regulatory Agency in Morocco. Actually, in the current version of Time Zone Database (https://www.iana.org/time-zones) for Africa region, and especially for Morocco, it’s mentionned that a program will be running to implement the transition dates. According to this program, the next transition dates (during 2023) are as below : - March 19, 2023 (switching to GMT). - April 30, 2023 (switching back to GMT+1). In fact, we will switch back to GMT+1, advancing 60 minutes, on Sunday, April 23 at 2:00 a.m (not on April 30). Please refer to the official annoncement, published by the Ministry of Digital Transition and Administration Reform: https://www.mmsp.gov.ma/fr/actualites/passage-%C3%A0-l%E2%80%99heure-gmt-%C… So, would you please update the program, in order to consider « April 23 at 2:00 a.m » (for switching back to GMT+1). Thank you in advance for your feedback and for your habitual support. Thank you. Best Regards, Afaf EL MAAYATI National Telecommunications Regulatory Agency Morocco [https://www.anrt.ma/images/ANRT-Signature.jpg] ________________________________ Ce message, son contenu et toutes les pièces jointes sont adressés à l'attention exclusive de leur (s) destinataire (s) et sont strictement confidentiels : ils relèvent de la correspondance privée. Toute publication, utilisation ou diffusion, même partielle, par des personnes autres que les destinataires est interdite et doit être autorisée par l'Agence Nationale de Règlementation des Télécommunications (ANRT, Royaume du Maroc). Si vous recevez ce message par erreur, nous vous prions de le détruire après en avoir informé son expéditeur sans délai. L’ANRT décline toute responsabilité pour toute altération, déformation ou falsification subi par le message et ses pièces jointes au cours de leur transmission. Retrouvez toutes les informations de l’ANRT sur son site Web à l’adresse suivante : http://www.anrt.ma. ________________________________ This message, its content and its attachments are intended for the exclusive use of the named addressee (s) and are strictly confidential. Any copy or other use of this information by persons or entities other than the intended recipient is prohibited and should be authorized by the National Agency of Telecommunications Regulation (ANRT, Morocco). If you have received this communication in error, please delete the material and notify the sender. The ANRT accepts no liability for any alteration, distortion or falsification that may occur during the transmission of this message. All information about ANRT can be found on our website at the following address http://www.anrt.ma. ________________________________ إن هذه الرسالة ومحتواها ومرفقاتها موجهة خصيصا للشخص المرسل إليه وتعتبر سرية وتصنف ضمن خانة المراسلات ذات طبيعة شخصية. ويمنع منعا كليا نشر أو استعمال أو بث، ولو بطريقة جزئية، لهذه الرسالة من طرف أشخاص غير المرسل إليهم ما لم يتم الترخيص بذلك من طرف الوكالة الوطنية لتقنين المواصلات (المملكة المغربية. في حالة ما إذا توصلتم هذه الرسالة عن طريق الخطأ، يرجى منكم العمل على إتلافها فورا بعد إخبار الشخص المرسل إليه بذلك. ولا تتحمل الوكالة الوطنية لتقنين المواصلات أي مسؤولية عن أي تحريف أو تغيير أو تزييف قد يلحق بمحتوى الرسالة أو بمرفقاتها خلال عملية الإرسال. للمزيد من المعلومات، يرجى الاطلاع على الموقع الإلكتروني للوكالة الوطنية لتقنين المواصلات : http://www.anrt.ma.

2 6

(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