October 2022 - 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

Buggy %z behaviour in strftime
by Almaz Mingaleev 16 May '23

16 May '23

Attached code prints "+0000 America/Los_Angeles" both with glibc and with linked ToT strftime implementation. On MacOs it prints "-0800 America/Los_Angeles". Is it a known issue?

10 19

Re: [tz] Morocco : Ramdan Time Change 2021
by Paul Eggert 15 Mar '23

15 Mar '23

On 3/19/21 3:15 AM, Semlali Naoufal wrote: > At the moment, we have no official government announcement to this effect. But, logically, the change to the GMT schedule should be made on the night of April 10-11, 2021 (last weekend before Ramadan). Yes, that's been the tzdb prediction too, ever since tzdb version 2018h (2018-12-23). For the record, here are tzdb's current predictions Morocco transitions during the next five years. Sun Apr 11 01:59:59 2021 UT = Sun Apr 11 02:59:59 2021 +01 Sun Apr 11 02:00:00 2021 UT = Sun Apr 11 02:00:00 2021 +00 Sun May 16 01:59:59 2021 UT = Sun May 16 01:59:59 2021 +00 Sun May 16 02:00:00 2021 UT = Sun May 16 03:00:00 2021 +01 Sun Mar 27 01:59:59 2022 UT = Sun Mar 27 02:59:59 2022 +01 Sun Mar 27 02:00:00 2022 UT = Sun Mar 27 02:00:00 2022 +00 Sun May 8 01:59:59 2022 UT = Sun May 8 01:59:59 2022 +00 Sun May 8 02:00:00 2022 UT = Sun May 8 03:00:00 2022 +01 Sun Mar 19 01:59:59 2023 UT = Sun Mar 19 02:59:59 2023 +01 Sun Mar 19 02:00:00 2023 UT = Sun Mar 19 02:00:00 2023 +00 Sun Apr 30 01:59:59 2023 UT = Sun Apr 30 01:59:59 2023 +00 Sun Apr 30 02:00:00 2023 UT = Sun Apr 30 03:00:00 2023 +01 Sun Mar 10 01:59:59 2024 UT = Sun Mar 10 02:59:59 2024 +01 Sun Mar 10 02:00:00 2024 UT = Sun Mar 10 02:00:00 2024 +00 Sun Apr 14 01:59:59 2024 UT = Sun Apr 14 01:59:59 2024 +00 Sun Apr 14 02:00:00 2024 UT = Sun Apr 14 03:00:00 2024 +01 Sun Feb 23 01:59:59 2025 UT = Sun Feb 23 02:59:59 2025 +01 Sun Feb 23 02:00:00 2025 UT = Sun Feb 23 02:00:00 2025 +00 Sun Apr 6 01:59:59 2025 UT = Sun Apr 6 01:59:59 2025 +00 Sun Apr 6 02:00:00 2025 UT = Sun Apr 6 03:00:00 2025 +01 Sun Feb 15 01:59:59 2026 UT = Sun Feb 15 02:59:59 2026 +01 Sun Feb 15 02:00:00 2026 UT = Sun Feb 15 02:00:00 2026 +00 Sun Mar 22 01:59:59 2026 UT = Sun Mar 22 01:59:59 2026 +00 Sun Mar 22 02:00:00 2026 UT = Sun Mar 22 03:00:00 2026 +01 Sun Feb 7 01:59:59 2027 UT = Sun Feb 7 02:59:59 2027 +01 Sun Feb 7 02:00:00 2027 UT = Sun Feb 7 02:00:00 2027 +00 Sun Mar 14 01:59:59 2027 UT = Sun Mar 14 01:59:59 2027 +00 Sun Mar 14 02:00:00 2027 UT = Sun Mar 14 03:00:00 2027 +01 Sun Jan 23 01:59:59 2028 UT = Sun Jan 23 02:59:59 2028 +01 Sun Jan 23 02:00:00 2028 UT = Sun Jan 23 02:00:00 2028 +00 Sun Mar 5 01:59:59 2028 UT = Sun Mar 5 01:59:59 2028 +00 Sun Mar 5 02:00:00 2028 UT = Sun Mar 5 03:00:00 2028 +01 Sun Jan 14 01:59:59 2029 UT = Sun Jan 14 02:59:59 2029 +01 Sun Jan 14 02:00:00 2029 UT = Sun Jan 14 02:00:00 2029 +00 Sun Feb 18 01:59:59 2029 UT = Sun Feb 18 01:59:59 2029 +00 Sun Feb 18 02:00:00 2029 UT = Sun Feb 18 03:00:00 2029 +01 Sun Dec 30 01:59:59 2029 UT = Sun Dec 30 02:59:59 2029 +01 Sun Dec 30 02:00:00 2029 UT = Sun Dec 30 02:00:00 2029 +00 Sun Feb 10 01:59:59 2030 UT = Sun Feb 10 01:59:59 2030 +00 Sun Feb 10 02:00:00 2030 UT = Sun Feb 10 03:00:00 2030 +01 Sun Dec 22 01:59:59 2030 UT = Sun Dec 22 02:59:59 2030 +01 Sun Dec 22 02:00:00 2030 UT = Sun Dec 22 02:00:00 2030 +00

3 9

Paraguay on its way to stay on DST
by Carlos Raúl Perasso 02 Mar '23

02 Mar '23

On September 28, the Paraguayan Chamber of Deputies approved a bill that eliminates winter time in Paraguay. This would make Paraguay stay in DST throughout the year. The project was sent to the Senate for approval. After this, it could still have the presidential veto. If successful, the law would take effect after this weekend's time change, so the new rule should read as follows: Rule Para 2010 2022 - Oct Sun>=1 0:00 1:00 - Rule Para 2013 2022 - Mar Sun>=22 0:00 0 - I will keep you informed of the progress of the bill. Saludos, Carlos

2 2

United States Senate reintroduced Sunshine Protection Act, enabling Permanent DST
by Phake Nick 14 Nov '22

14 Nov '22

I don't quite understand the legal text of the bill itself [2], but according to my reading, it seems like the bill will end DST across the entire US by shifting the standard time forward an hour, except in states/territories/area that currently doesn't enact DST, which they can choose to follow the new standard time or old standard time? 1: https://www.rubio.senate.gov/public/index.cfm/2021/3/rubio-colleagues-reint… 2: https://www.rubio.senate.gov/public/_cache/files/d34c77c0-acea-4074-bc57-14…

18 26

No Daylight Savings in Fiji For year 2022-2023
by Jashneel Kumar 08 Nov '22

08 Nov '22

Dear Timezone Support, I would like to inform you that there will be no Daylight Saving in Fiji this year. Can you please check that the same is reflected in the time zone database. Regards, [New_VF_Icon_RGB_RED] Jashneel Kumar Manager Data Networks & Services Jashneel.Kumar(a)vodafone.com.fj<mailto:Jashneel.Kumar@vodafone.com.fj> Vodafone Fiji PTE Limited, 168 Princes Rd, Tamavua, Suva, Fiji Islands www.vodafone.com.fj<http://www.vodafone.com.fj/> Together we can [Vodafone] ________________________________ The content of this email including any attachments is confidential and may contain information that is proprietary and privileged. If you are not the intended recipient be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify E-mail Administrator on info(a)vodafone.com.fj Please also destroy and delete this message from your system. Vodafone Fiji PTE Limited does not guarantee that this message is free from computer virus or any other defect. The reader accepts full responsibility for taking defensive and counteractive action needed to rectify the computer virus or other defects caused. Vodafone Fiji PTE Limited : Private Mail Bag, Suva, Fiji | Telephone : +679 3312000 | E-Mail : info(a)vodafone.com.fj Please consider your environmental responsibility before printing this e-mail [https://www.vodafone.com.fj//images/default-source/logo/logo-2x.png] Vodafone Fiji PTE Ltd <https://www.vodafone.com.fj/>

3 5

Mexico on track to abolish DST
by Paul Eggert 03 Nov '22

03 Nov '22

Yesterday Mexico's Chamber of Deputies voted 445–33 to abolish DST in most of Mexico, and although there are more hurdles I expect this to become law. When that happens, I hope the following simple patch will suffice; it merely changes "max" to "2022" in the last two Mexico Rule lines. We'll also need to add commentary citing the law, etc., but you can try this patch now if you like, to debug any applications involving future time in Mexico. Today timeanddate updated their English-language summary of this <https://www.timeanddate.com/news/time/mexico-remove-dst-2022.html>. I haven't installed the following. diff --git a/northamerica b/northamerica index da84f354..2466d627 100644 --- a/northamerica +++ b/northamerica @@ -2634,2 +2634,2 @@ Rule Mexico 2001 only - Sep lastSun 2:00 0 S -Rule Mexico 2002 max - Apr Sun>=1 2:00 1:00 D -Rule Mexico 2002 max - Oct lastSun 2:00 0 S +Rule Mexico 2002 2022 - Apr Sun>=1 2:00 1:00 D +Rule Mexico 2002 2022 - Oct lastSun 2:00 0 S

4 16

Re: [tz] iana build failures on Windows
by Paul Eggert 02 Nov '22

02 Nov '22

On 4/19/21 7:09 AM, Manuela Friedrich wrote: > I had to include signal.h in zic.c to prevent the following error: > > zic.c(610): error C2061: syntax error: identifier 'got_signal' This is a portability bug recently introduced to zic.c. I installed the first attached patch to fix it. > The I needed to resolved error > > zic.obj : error LNK2019: unresolved external symbol tz_time referenced in function random_dirent This appears to be another recent portability bug. It's related to a portability problem you reported on MS-Windows in response to which in 2018d I committed a patch that introduced RESERVE_STD_EXT_IDS: https://github.com/eggert/tz/commit/24b45243c5210b4196987fdd06e6c288c358a268 When I recently added the randomish filename code to the development version, I neglected to deal with RESERVE_STD_EXT_IDS. The second attached patch should fix this issue. Please give the two patches a try, as I don't use MS-Windows and can't easily test these patches on that platform. > a test run of zdump -v produced way more output than in the last release, the Linux output seems to have become longer too, but maybe this is still under development. That change is intentional, and was caused by this: https://github.com/eggert/tz/commit/ac07b446a3afaa4cb1ae11a91785a201c91f6351 along with some neighboring commits. Thanks for reporting the problems, and I hope the current development version of tzdb addresses the issues you mentioned.

5 23

Errors compiling 2022f on macOS
by Gilmore Davidson 31 Oct '22

31 Oct '22

Hi, I’m getting errors when running make on the 2022f release, on my macOS Monterrey (12.6.1) machine. There are two separate errors. When I run `make` with no arguments, I get the following: cc -DTZDIR='"/usr/share/zoneinfo"' -c -o zic.o zic.c zic.c:1194:11: error: implicit declaration of function 'getrandom' is invalid in C99 [-Werror,-Wimplicit-function-declaration] s = getrandom(entropy_buffer, sizeof entropy_buffer, 0); ^ 1 error generated. After some digging, I tried running `make CFLAGS="-DHAVE_GETRANDOM=0”`, which then presents a different error: cc -DTZDIR='"/usr/share/zoneinfo"' -o zic -DHAVE_GETRANDOM=0 zic.o Undefined symbols for architecture x86_64: "_libintl_gettext", referenced from: _main in zic.o _close_file in zic.o _usage in zic.o _warning in zic.o _infile in zic.o _adjleap in zic.o _associate in zic.o ... "_libintl_setlocale", referenced from: _main in zic.o "_libintl_textdomain", referenced from: _main in zic.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) I’m not a C programmer so I’m out of my depth with trying to diagnose workarounds. Possibly there’s just another CFLAGS argument I need to provide, or I’ve got something else weird in my environment? Some extra bits of context: These errors also happen on latest `main` branch (commit 9f1f40cd). I can compile 2022e without issue. The getrandom error appears in commit 0733c65c ("Improve randomness of zic temp file names”). The linking error appears in commit e5b2ee63 ("Use C23 __has_include if available”). masOS 12.6.1 / Make 3.81 / clang 14.0.0 Also, the Makefile comment for the HAVE_GETRANDOM flag says "-DHAVE_GETRANDOM if getgrandom works (e.g., GNU/Linux)*” — is “getgrandom” a typo? Cheers, Gil

4 13

zic.c - compilation broken on gcc 4.8.3 after commit e5b2ee634c7151484c06740ea2c8a4d4a75409b6
by Иванов Игорь 31 Oct '22

31 Oct '22

Good time of day. This commit breaks compilation at least on GCC 4.8.3: commit e5b2ee634c7151484c06740ea2c8a4d4a75409b6 Author: Paul Eggert <eggert(a)cs.ucla.edu> Date: Thu Oct 20 11:41:27 2022 -0700 Use C23 __has_include if available It causes this compilation error: zic.c: In function ‘main’: zic.c:813:16: error: ‘optarg’ undeclared (first use in this function) if (strcmp(optarg, "slim") == 0) { ^ zic.c:906:6: error: ‘optind’ undeclared (first use in this function) if (optind == argc - 1 && strcmp(argv[optind], "=") == 0) ^ Specifically hunks like this are problematic: @@ -55,8 +63,8 @@ #endif #ifndef HAVE_GETTEXT -# define HAVE_GETTEXT 0 -#endif /* !defined HAVE_GETTEXT */ +# define HAVE_GETTEXT HAS_INCLUDE(<libintl.h>, false) +#endif #ifndef HAVE_INCOMPATIBLE_CTIME_R # define HAVE_INCOMPATIBLE_CTIME_R 0 The culprit is the replacement 0 -> false and 1 -> true. Apparently it breaks #if preprocessor logic in older compilers somewhere downstream - what was #if 1 becomes #if true, which GCC treats as "false" and falls into #else branch. "Restoring" false and true back to 0 and 1 seems to fix the issue. Best regards, Igor Ivanov, Software engineer at DSSL

2 3