- tz - lists.iana.org

Lebanon DST last minute postponed, IANA not informed!
by Jad Baz March 23, 2023

March 23, 2023

Dear timezone coordinators, My name is Jad Baz, I am a software engineer from Lebanon I just wanted to bring to your attention an issue concerning Lebanon's last minute cancellation of DST this Sunday (March 26th 2023) Lebanon, as part of the EEST timezone, is supposed to enter in DST this Sunday However, this was postponed due to Ramadan It was announced today (Thu March 23rd) by several news outlets that the Secretary General of the Council of Ministers decided to change postpone DST from this Sunday March 26th to April 21st Below, you will find a few links to news articles in English from trusted Lebanese news agencies: - https://www.lbcgroup.tv/news/lebanon-news/693669/lebanon-postpones-daylight… - https://www.mtv.com.lb/news/local/1352516/lebanon-postpones-daylight-saving… I checked the latest IANA updates from March 22nd and did not find mention of this latest development I think this decision was taken haphazardly without much regard for how this change will be propagated (as are most decisions in Lebanon, sadly...) I know my question is coming quite last minute But I'm wondering what needs to be done to save the situation as this is causing a lot of chaos (eg airlines) I looked at the procedures doc and initially thought that there must be some formal communication that needs to go out from government employees but it seems that "what the average person on street would think the time actually is" is enough So my questions are: - Are the above articles enough to make this change? Or is there any other data you need that I can help with? - Do you expect this might be amended by Sunday? If not, what's a more realistic estimate of a schedule? Thank you very much, Jad Baz

1 0

DST Change in Lebanon
by Rany Hany March 23, 2023

March 23, 2023

Hello, Lebanon has extended daylight savings time until April 20 2023 (exceptionally this year). It's so that people fasting this ramadan stop their fasting at 5PM instead of 6PM. Sources: - https://twitter.com/grandserail/status/1638874765954785280 - https://twitter.com/timourazhari/status/1638877448447115266 Best

1 0

Fwd: [tz-announce] 2023a release of tz code and data available
by Saadallah Itani March 23, 2023

March 23, 2023

1 0

Asia/Bangkok
by Chris Walton March 22, 2023

March 22, 2023

Paul, Sorry for the timing of this message; I know you are in the middle of trying to push out 2023a. At some point in the last few months the description of Asia/Bangkok in zone1970.tab changed from "Indochina (most areas)" to "north Vietnam". Is this really what you intended? -chris

2 1

[tz-announce] 2023a release of tz code and data available
by Paul Eggert via tz-announce March 22, 2023

March 22, 2023

The 2023a release of the tz code and data is available. This release contains the following changes: Briefly: Egypt now uses DST again, from April through October. This year Morocco springs forward April 23, not April 30. Palestine delays the start of DST this year. Much of Greenland still uses DST from 2024 on. America/Yellowknife now links to America/Edmonton. tzselect can now use current time to help infer timezone. The code now defaults to C99 or later. Fix use of C23 attributes. Changes to future timestamps Starting in 2023, Egypt will observe DST from April's last Friday through October's last Thursday. (Thanks to Ahmad ElDardiry.) Assume the transition times are 00:00 and 24:00, respectively. In 2023 Morocco's spring-forward transition after Ramadan will occur April 23, not April 30. (Thanks to Milamber.) Adjust predictions for future years accordingly. This affects predictions for 2023, 2031, 2038, and later years. This year Palestine will delay its spring forward from March 25 to April 29 due to Ramadan. (Thanks to Heba Hamad.) Make guesses for future Ramadans too. Much of Greenland, represented by America/Nuuk, will continue to observe DST using European Union rules. When combined with Greenland's decision not to change the clocks in fall 2023, America/Nuuk therefore changes from -03/-02 to -02/-01 effective 2023-10-29 at 01:00 UTC. (Thanks to Thomas M. Steenholdt.) This change from 2022g doesn't affect timestamps until 2024-03-30, and doesn't affect tm_isdst until 2023-03-25. Changes to past timestamps America/Yellowknife has changed from a Zone to a backward compatibility Link, as it no longer differs from America/Edmonton since 1970. (Thanks to Almaz Mingaleev.) This affects some pre-1948 timestamps. The old data are now in 'backzone'. Changes to past time zone abbreviations When observing Moscow time, Europe/Kirov and Europe/Volgograd now use the abbreviations MSK/MSD instead of numeric abbreviations, for consistency with other timezones observing Moscow time. Changes to code You can now tell tzselect local time, to simplify later choices. Select the 'time' option in its first prompt. You can now compile with -DTZNAME_MAXIMUM=N to limit time zone abbreviations to N bytes (default 255). The reference runtime library now rejects POSIX-style TZ strings that contain longer abbreviations, treating them as UTC. Previously the limit was platform dependent and abbreviations were silently truncated to 16 bytes even when the limit was greater than 16. The code by default is now designed for C99 or later. To build in a C89 environment, compile with -DPORT_TO_C89. To support C89 callers of the tzcode library, compile with -DSUPPORT_C89. The two new macros are transitional aids planned to be removed in a future version, when C99 or later will be required. The code now builds again on pre-C99 platforms, if you compile with -DPORT_TO_C89. This fixes a bug introduced in 2022f. On C23-compatible platforms tzcode no longer uses syntax like 'static [[noreturn]] void usage(void);'. Instead, it uses '[[noreturn]] static void usage(void);' as strict C23 requires. (Problem reported by Houge Langley.) The code's functions now constrain their arguments with the C 'restrict' keyword consistently with their documentation. This may allow future optimizations. zdump again builds standalone with ckdadd and without setenv, fixing a bug introduced in 2022g. (Problem reported by panic.) leapseconds.awk can now process a leap seconds file that never expires; this might be useful if leap seconds are discontinued. Changes to commentary tz-link.html has a new section "Coordinating with governments and distributors". (Thanks to Neil Fuller for some of the text.) To improve tzselect diagnostics, zone1970.tab's comments column is now limited to countries that have multiple timezones. Note that leap seconds are planned to be discontinued by 2035. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2023a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2023a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2023a.tar.lz The following convenience links are also available, although they may point to the previous release until the relevant caches are refreshed: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit f24b84a13556c12441dd55c323f9a8fd3b6fbbee dated 2023-03-22 12:39:33 -0700 and tagged '2023a' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: d45fc677a0a32ae807bf421faceff675565ee15e3ff42d3a4121df10e1f7855ac16b27fbc28bd365f93c57f40c5bdf19cde88546f7090cfab7676cac0a5516a4 tzcode2023a.tar.gz 10aadd6eba50f63f427399281065ba34cb474f6a854f8dc7a6f4f1343b1474a05f22b69b1e113ea67bb5f3f479253610a16b89d9dfa157bf0fde4c69aa3d6493 tzdata2023a.tar.gz 8e959f6cad84e9481ed5a6efcc8d7126d41fadfdc860715fea87fb15f7dcfdbc4c9d49828df2945ee9304dbdd3370c5b5048c62637bdd4f4962830ba101008bd tzdb-2023a.tar.lz Here are GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmQbXA8ACgkQ7ZfpDmKq fjSDXRAAjfD1GMYAFHDvXOlCCitgTsTjBBuPHPbrQ7gTWno9uX8bvss3aXCUslHv sfzCHMKhJqMXGLzSQQ5jEP/k4fOjNJyIQbVlrY9XljpdGeOdYa1E0zr95dIf4/ta NUY9XxzFnd3hwQuc6LY77MOv2Xyy/5RAGajD2DTpYTLjE0ffMFK371efs//GcLqe aCIWBdet1rJyih6CoyzfNvl6QHQOxZLSlE2E3DYu430fTi/UhmTcaATW8gRNulL5 kXamzD9l45/cGOx/jHP6CkJIqFTFV4W1/W/VyjIEgRE0KGbuQO3LV0avohjhmmwm hS6H6RJYfgeF+vwmo3unN+vUwPLhkPUiz2NO/Uf0n22AVQlUOrEP0XVXYW8aRd3H ewDrlvDCMkvmKqEb8k0jqbmjqTgeblKoqeS7gIShhVmrIli8oN4mguWg5WaeRWF/ l3uYtBXOg/DJMwENrB+4u0+PRWuR2T5OW/E4NvaKIu58qzozP7WEmlEwv9KWZB+z ffmNaVgXqSCz50K6gvhoDKLn5YBgpB9kXDd+YrcqPUAyD0sDWhBC2Hx9HHePOfQl dFB+ijja5HB8aZD/rX0iLrSwp/Ndt4l2QjXY9SMjTiWx4SgGGmGCANQqCDZGD31a C8bdEMH4qQeOPZ/NsPB6KaJsqALNroF07YeINu0YfWkw89ZF/r4= =mRAo -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmQbXA8ACgkQ7ZfpDmKq fjRngg/8D8E5sJIt412pmR7yIQYnsG44nSiELNpiewG+SF4DofW7quQDQEjDMdVn seLU9okE1/l+1SN6eibMJgvho/6HWkU9kWLzYCY29sljTVYqEu6vLo1IY1OJIkjC 9yieL33oLkN4LIeSMzR4QOCkRfusYNRYq3uryVtMu7R6HP2PgMlmmJf/imV192tj ONJXNA4Y30EvJ3lHuXMbr7fNg9hXSLjRy1NPKjp5OVZ3jZVXPljrC+egAfhLjZdQ uB5a3uGjAX+KjemCHwTmrrmmcUlaHxFxlfN5gX5cNIXuyrYtz0PAhy+MhBM5F9iY erYWg6EfBr7IfSyS1JcDZ1ypwZ66EpKxXfWZNm+HFA4dDdnWgvlM4n1OyKjw03Dq 4/agYr34cUDhfBUS57dtpZSibtdpbh8oiqxc+wXV3KZcHXVpX3XRyGTH1UVINfnF nXArC09JKUt7Tjol83TPH0jDXJAxabkgUDJHfpeQ5A8r3GNW1PQ/OF25ieRb+AFQ jWFbiEIxSXmUwnRc6wHiLX/gU0TT7vVMokN5erx9IGwrDEQAljuEJoj2bYFT/q9D 8jFA+48r/nK2r33+OBrz6aryoMNptquuMG0XR4aSr6KO3e622+vuF4nSN7hg2sAM /bMLSlzOGUEmOZ2D7hP5MDdWw5L0WQAjX7/8xKzdlMhqkx4Mc9Q= =OxWX -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmQbXBAACgkQ7ZfpDmKq fjQJaQ//aj78DFo7hiHX7VNnyEIKdddIApk6PKN6XkfCxVyXDxztE9w4Bf8LhYR2 hw0TFDtaIDpW0tb6OTQ/r/I2xMmeYKT52YPKL6KtKmc8tmzM4DiBT0CT/c//nxSl elxnuRI1wPbvP21XjuqbKBztN7ID1KC6YAs78045Cek+1K1lx5z9QcnYNLGIBwn3 EP4zi3qkMKQRKuT07ESQy4+y7hezPy9CPZMObmQ/v4nmUk0OIvbHGBK0TAc8D6kI Tsv1mAk4FHnbpbtpdXwfGDGpYfBs8giMHH6M+ZGdaT452hKrOwCgrvzsGlOxsxDc Ht4iASO78OEjdA/5cEscYYdoxOQCcTeDQEfWYx5bNfCFNvUKzrs79Qs1GaQ9riXW zdRBjW0sKbKZUoM9ZPjtYxRfh8PrZY9qDoZ4orF/39jl3SkBYkCC8IsKtEEVUYm/ ELH930IXmJ49sVdl+9ROGgqGUPcaVfouZf/+qf8d6HSEolOgrXe9FkB9E42RLBXw ETO/yL0MHPRiJU8U2agRV3AMiJoxM07ZvH54BgAsSXl1vr7xaCMqy5B38R7U/Tmj Sp7pqvtKhUcqyLHRi073GZmdV3pFhRsfAgiXTpRdNTAyJpN+y6jO9pZg6YYEfb+w kql/6Gp76ffGQU1j3OnvmVnmS22a34WiBZ0iYsKhrU/sym3Pk88= =SZ+n -----END PGP SIGNATURE-----

1 0

Summer Time in Palestine for 2023s year
by heba.hamad March 22, 2023

March 22, 2023

3 2

Re: [tz] [tzcode 2022g] Undeclared variable/typo in zdump.c
by Paul Eggert March 22, 2023

March 22, 2023

On 2023-03-22 02:55, panic wrote: > I contact you directly, because access to the mailing list is currently > very limited (new subscriber). Thanks, I'll include a copy of your email below, so that other subscribers of the tz mailing list can see it. > I try to cross-compile tzcode 2022g from GNU/Linux (NixOS) to Windows > using GCC 12.2.0 (x86_64-w64-mingw32) and get this compilation error: > >> In file included from zdump.c:14: >> zdump.c: In function 'zdump_tzalloc': >> zdump.c:264:38: error: 'initial_envptrs' undeclared (first use in this function); did you mean 'initial_nenvptrs'? >> 264 | if (ckd_add(&initial_nenvptrs, initial_envptrs, 1) >> | ^~~~~~~~~~~~~~~ >> private.h:414:51: note: in definition of macro 'ckd_add' >> 414 | # define ckd_add(r, a, b) __builtin_add_overflow(a, b, r) >> | ^ >> zdump.c:264:38: note: each undeclared identifier is reported only once for each function it appears in >> 264 | if (ckd_add(&initial_nenvptrs, initial_envptrs, 1) >> | ^~~~~~~~~~~~~~~ >> private.h:414:51: note: in definition of macro 'ckd_add' >> 414 | # define ckd_add(r, a, b) __builtin_add_overflow(a, b, r) >> | ^ >> make: *** [<builtin>: zdump.o] Error 1 > > I suspect `initial_envptrs` is a typo and should be `initial_nenvptrs`, > as the former does not occur anywhere else. > > Building natively for Linux works just fine. For cross-compilation, I > build additionally with > >> "CFLAGS+=-DHAVE_DIRECT_H" >> "CFLAGS+=-DHAVE_SETENV=0" >> "CFLAGS+=-DHAVE_SYMLINK=0" >> "CFLAGS+=-DRESERVE_STD_EXT_IDS" > > `-DHAVE_SETENV=0` selects the alternative path in `zdump_tzalloc` and in > combination with a recent GCC triggers error. Normally, `HAVE_SETENV=1` > and the code path is not compiled. Maybe the combination of a recent GCC > and > `-DHAVE_SETENV=0` is rarely tested and therefore the typo was not > discovered before. > > Cheers, > -- panic Thanks for the bug report. I've never built with that particular combination, and you exposed a couple of typos. I reproduced the problem artificially on GNU/Linux by building with "make CFLAGS='-DHAVE_SETENV=0'" and installed the attached patches. This fix should appear in the next release, which should be soon.

1 0

[PATCH] Pacify gcc -Wunused-parameter
by Paul Eggert March 22, 2023

March 22, 2023

* zdump.c (localtime_rz, tzfree): [! USE_LOCALTIME_RZ]: Mark unused args with ATTRIBUTE_MAYBE_UNUSED. Problem found when compiling with -DUSE_LTZ=0 on Fedora 37 with GCC 12.2.1 20221121 (Red Hat 12.2.1-4). --- zdump.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zdump.c b/zdump.c index 77ecb18..88bcd3a 100644 --- a/zdump.c +++ b/zdump.c @@ -228,7 +228,7 @@ localtime_r(time_t *tp, struct tm *tmp) # undef localtime_rz # define localtime_rz zdump_localtime_rz static struct tm * -localtime_rz(timezone_t rz, time_t *tp, struct tm *tmp) +localtime_rz(ATTRIBUTE_MAYBE_UNUSED timezone_t rz, time_t *tp, struct tm *tmp) { return localtime_r(tp, tmp); } @@ -304,7 +304,7 @@ tzalloc(char const *val) } static void -tzfree(timezone_t initial_environ) +tzfree(ATTRIBUTE_MAYBE_UNUSED timezone_t initial_environ) { # if !HAVE_SETENV environ = initial_environ; -- 2.39.2

1 0

Time Zone Database
by EL MAAYATI Afaf March 22, 2023

March 22, 2023

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 3

Maryland bill status
by Arthur David Olson March 21, 2023

March 21, 2023

Crossover day has come and gone in the Maryland state legislature; bills not passed by one of the two chambers by crossover face substantial hurdles in gaining approval. Neither the House-side nor the Senate-side bills shifting Maryland to permanent DST (with the potential for a short-notice shift) made it out of committee. Links to bill status below. My guess: the bill (it's actually the same bill, cross-filed) will be back next year.-( @dashdashado https://mgaleg.maryland.gov/mgawebsite/Legislation/Details/hb0165?ys=2023rs https://mgaleg.maryland.gov/mgawebsite/Legislation/Details/sb0268?ys=2023rs

1 0