July 2023 - 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

Did Greenland abolish daylight saving from 2024 on?
by Paul Eggert Nov. 20, 2023

Nov. 20, 2023

This week several English-language news sources reported that Greenland has moved its clocks forward for the last time. These reports disagree with current TZDB[1], which follows Thomas M. Steenholdt's December email[2] saying that although in November Greenlanders voted to not fall back this fall, they also voted to continue to observe daylight saving time (DST) next year, effectively moving their time zone one hour east instead of abolishing DST. There's no disagreement about timekeeping this year. The first point of disagreement is March 30, 2024 at 23:00, when TZDB says Nuuk, Greenland will spring forward to 24:00, whereas the recent news reports say clocks will neither spring forward nor fall back during 2024. So who's right: Steenholdt in December, or these several recent news reports? Currently TZDB goes with Steenholdt. After all, he cited the relevant Greenland legislation and his email address ends in ".gl". I suppose another possibility, though, is that Greenland's government has changed its mind since November. However, if so I'd like to see citations to the newer legislation. The earliest recent news story I found on this topic was a week ago by Lebawit Lily Girma[3], senior travel news reporter for Bloomberg Pursuits. I'm taking the liberty of bcc'ing Girma to see if she can help get to the bottom of the situation. [1]: https://iana.org/tz [2]: https://mm.icann.org/pipermail/tz/2022-December/032402.html [3]: Girma LL. Greenland Solves the Daylight Saving Time Debate. Bloomberg. 2023-03-24. https://www.bloomberg.com/news/articles/2023-03-24/greenland-keeps-daylight… Here are some of the other news reports I found. Greenland to stay in daylight saving time forever. AP. 2023-03-27. https://apnews.com/article/greenland-daylight-saving-summertime-utc-gmt-3b5… Martin M. Greenland is keeping daylight saving time permanently. NPR. 2023-03-28. https://www.wunc.org/2023-03-28/greenland-is-keeping-daylight-saving-time-p… Selcho M. Here’s why Greenland is permanently keeping daylight saving time. Deseret News. 2023-03-28. https://www.deseret.com/u-s-world/2023/3/28/23660379/why-greenland-keeping-… Jerusalem Post staff. Greenland changed their clocks to daylight savings for the last time. Jerusalem Post. 2023-03-29. https://www.jpost.com/international/article-735751 Carpineti A. Greenland Has Changed Its Clocks For The Last Time, Embracing Daylight Savings Forever. IFLScience. 2023-03-29. https://www.iflscience.com/greenland-has-changed-its-clocks-for-the-last-ti…

16 48

Danish standard time will probably officially be based on UTC
by Jonas Nyrup Sept. 9, 2023

Sept. 9, 2023

Since 1893-03-29 Danish standard time has been defined as "the mean solar time for the 15th degree of longitude east of Greenwich" (machine translated of the offical law). With the introduction of UTC we didn't update that law, but we did start using UTC+1 as standard time in practice. So for around 50 years maybe only astronomers have been following the law. The Minister of Transportation has now proposed a bill to update the law to define Danish standard time as UTC+1 to keep up with reality. At the first reading all political parties expressed their support and jokingly noted that "it was about time". The updated law is expected to take effect on 2023-03-26. The current law: https://www.retsinformation.dk/eli/lta/1893/83 The bill: https://www.ft.dk/samling/20222/lovforslag/l19/index.htm Tom Scott on the subject: https://www.youtube.com/watch?v=yRz-Dl60Lfc Jonas Nyrup

2 1

[PROPOSED] Document Paraguay’s recently-passed Law No. 7115
by Paul Eggert July 28, 2023

July 28, 2023

This law doesn’t change TZDB’s data; it merely codifies into law recent common practice as implemented by presidential decrees. * southamerica: Add comments re Law No. 7115. --- southamerica | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/southamerica b/southamerica index e55c5f08..9430b185 100644 --- a/southamerica +++ b/southamerica @@ -1697,6 +1697,12 @@ Rule Para 2010 2012 - Apr Sun>=8 0:00 0 - # From Carlos Raúl Perasso (2014-02-28): # Decree 1264 can be found at: # http://www.presidencia.gov.py/archivos/documentos/DECRETO1264_ey9r8zai.pdf +# +# From Paul Eggert (2023-07-26): +# Transition dates are now set by Law No. 7115, not by presidential decree. +# https://www.abc.com.py/politica/2023/07/12/promulgacion-el-cambio-de-hora-s… +# Although Google indexed this government URL, it did not work for me: +# https://www.bacn.gov.py/leyes-paraguayas/11831/ley-n-7115-establece-el-hora… Rule Para 2013 max - Mar Sun>=22 0:00 0 - # Zone NAME STDOFF RULES FORMAT [UNTIL] -- 2.39.2

3 4

[PATCH] Improve touches when making tarballs
by Paul Eggert July 27, 2023

July 27, 2023

* Makefile (SET_TIMESTAMP_N, set-timestamps.out) (tzdata$(VERSION)-rearguard.tar.gz, tzdata$(VERSION)-tailored.tar.gz): Do not use ‘touch -c’, as POSIX says it exits with status 0 even when it fails. Instead, check in the shell that a file exists before touching it. Chatter with “+ touch ...” before touching, to aid debugging of failures. --- Makefile | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/Makefile b/Makefile index d891f837..68c644d8 100644 --- a/Makefile +++ b/Makefile @@ -958,12 +958,18 @@ $(MANTXTS): workman.sh # plus N if GNU ls and touch are available. SET_TIMESTAMP_N = sh -c '\ n=$$0 dest=$$1; shift; \ - touch -cmr `ls -t "$$@" | sed 1q` "$$dest" && \ + <"$$dest" && \ if test $$n != 0 && \ - lsout=`ls -n --time-style="+%s" "$$dest" 2>/dev/null`; then \ + lsout=`ls -nt --time-style="+%s" "$$@" 2>/dev/null`; then \ set x $$lsout && \ - touch -cmd @`expr $$7 + $$n` "$$dest"; \ - else :; fi' + timestamp=`expr $$7 + $$n` && \ + echo "+ touch -md @$$timestamp $$dest" && \ + touch -md @$$timestamp "$$dest"; \ + else \ + newest=`ls -t "$$@" | sed 1q` && \ + echo "+ touch -mr $$newest $$dest" && \ + touch -mr "$$newest" "$$dest"; \ + fi' # If DEST depends on A B C ... in this Makefile, callers should use # $(SET_TIMESTAMP_DEP) DEST A B C ..., for the benefit of any # downstream 'make' that considers equal timestamps to be out of date. @@ -992,7 +998,8 @@ set-timestamps.out: $(EIGHT_YARDS) --format='tformat:%cd' \ --date='format:%Y-%m-%dT%H:%M:%SZ' \ $$file` && \ - touch -cmd $$time $$file; \ + echo "+ touch -md $$time $$file" && \ + touch -md $$time $$file; \ else \ echo >&2 "$$file: warning: does not match repository"; \ fi || exit; \ @@ -1148,7 +1155,7 @@ tzdata$(VERSION)-rearguard.tar.gz: rearguard.zi set-timestamps.out sed '1s/$$/-rearguard/' <version >$@.dir/version : The dummy pacificnew pacifies TZUpdater 2.3.1 and earlier. $(CREATE_EMPTY) $@.dir/pacificnew - touch -cmr version $@.dir/version + touch -mr version $@.dir/version LC_ALL=C && export LC_ALL && \ (cd $@.dir && \ tar $(TARFLAGS) -cf - \ @@ -1172,7 +1179,7 @@ tzdata$(VERSION)-tailored.tar.gz: set-timestamps.out `test $(DATAFORM) = vanguard || echo pacificnew` (grep '^#' tzdata.zi && echo && cat $(DATAFORM).zi) \ >$@.dir/etcetera - touch -cmr tzdata.zi $@.dir/etcetera + touch -mr tzdata.zi $@.dir/etcetera sed -n \ -e '/^# *version *$.*$/h' \ -e '/^# *ddeps */H' \ @@ -1183,7 +1190,7 @@ tzdata$(VERSION)-tailored.tar.gz: set-timestamps.out -e 's/ /-/g' \ -e 'p' \ <tzdata.zi >$@.dir/version - touch -cmr version $@.dir/version + touch -mr version $@.dir/version links= && \ for file in $(TZDATA_DIST); do \ test -f $@.dir/$$file || links="$$links $$file"; \ -- 2.39.2

1 0

[PATCH] Port better to POSIX 'touch'
by Paul Eggert July 26, 2023

July 26, 2023

* Makefile (set-timestamps.out): Use POSIX syntax for 'touch -d' rather than relying on a GNU extension. --- Makefile | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 17e73891..d891f837 100644 --- a/Makefile +++ b/Makefile @@ -988,8 +988,11 @@ set-timestamps.out: $(EIGHT_YARDS) rm -f test.out && \ for file in $$files; do \ if git diff --quiet $$file; then \ - time=`git log -1 --format='tformat:%ct' $$file` && \ - touch -cmd @$$time $$file; \ + time=`TZ=UTC0 git log -1 \ + --format='tformat:%cd' \ + --date='format:%Y-%m-%dT%H:%M:%SZ' \ + $$file` && \ + touch -cmd $$time $$file; \ else \ echo >&2 "$$file: warning: does not match repository"; \ fi || exit; \ -- 2.39.2

2 3

Problem with some timezone data from 2023 w/ Java SimpleTimeZone
by Andreas Haumer July 19, 2023

July 19, 2023

Hi! [I hope this is the right place to report this problem. I reported it on OpenSUSE bugzilla, but was asked to report it upstrem, too. See https://bugzilla.opensuse.org/show_bug.cgi?id=1213470 for my original bugreport] A few days ago I found that with the 2023c timezone database as installed on OpenSUSE LEAP or RedHat Fedora there are two timezones which produce an IllegalArgumentException in the SimpleTimeZone Java class (from OpenJDK 17): "Asia/Gaza" and "Asia/Hebron" The following small Java programm demonstrates the problem: andreas@localhost:~> cat TimeZoneTest.java import java.util.TimeZone; public class TimeZoneTest { public static void main(String[] argv) { for (final String id : TimeZone.getAvailableIDs()) try { TimeZone.getTimeZone(id).toString(); } catch (Exception ex) { System.out.println("TimeZone " + id + " failed: " + ex); } } } Running this programm with a current Java timezone database installed gives the following output: andreas@localhost:~> java TimeZoneTest.java TimeZone Asia/Gaza failed: java.lang.IllegalArgumentException: Illegal daylight saving value: 0 TimeZone Asia/Hebron failed: java.lang.IllegalArgumentException: Illegal daylight saving value: 0 andreas@localhost:~> rpm -q timezone-java timezone-java-2023c-150000.75.23.1.noarch andreas@localhost:~> java -version openjdk version "17.0.7" 2023-04-18 OpenJDK Runtime Environment (build 17.0.7+0-suse-150400.3.24.1-x8664) OpenJDK 64-Bit Server VM (build 17.0.7+0-suse-150400.3.24.1-x8664, mixed mode, sharing) This is with OpenSUSE LEAP 15.4 and 15.5 I also see the same exceptions with Fedora 37, which also uses a separate 2023c timezone database for Java. Debian based systems (like Debian 11, Debian 12 or Ubuntu 22) run the above program without error. They use the internal tzdb which comes with OpenJDK. It looks like the timezone database contains a 0 for the dstSavings property. The constructor for the SimpleTimeZone Java class wants this calue to be > 0 and throws an IllegalArgumentException if it isn't: public SimpleTimeZone(int rawOffset, String ID, int startMonth, int startDay, int startDayOfWeek, int startTime, int startTimeMode, int endMonth, int endDay, int endDayOfWeek, int endTime, int endTimeMode, int dstSavings) { setID(ID); this.rawOffset = rawOffset; this.startMonth = startMonth; this.startDay = startDay; this.startDayOfWeek = startDayOfWeek; this.startTime = startTime; this.startTimeMode = startTimeMode; this.endMonth = endMonth; this.endDay = endDay; this.endDayOfWeek = endDayOfWeek; this.endTime = endTime; this.endTimeMode = endTimeMode; this.dstSavings = dstSavings; // this.useDaylight is set by decodeRules decodeRules(); if (dstSavings <= 0) { throw new IllegalArgumentException("Illegal daylight saving value: " + dstSavings); } } So: is this a problem with the timezone database or rather a problem with the implementation of the Java SimpleTimeZone class? Thanks! - andreas -- Andreas Haumer *x Software + Systeme | mailto:andreas@xss.co.at Karmarschgasse 51/2/20 | https://www.xss.co.at/ A-1100 Vienna, Austria | Tel: +43-1-6060114-0

3 2

Issue with timezone
by Ty Hanks July 18, 2023

July 18, 2023

Having an issue with timezone ‘America/Bogota’ should be the same as ‘America/NewYork’ but if you pull time based on it from pytz which uses your database. You get the wrong timezone a 3 or 4 hour ahead timezone. Feel free to ask for more testing info if needed .. Thanks

4 3