- tz - lists.iana.org

How Time Zones Are Coordinated
by Kim Davies March 15, 2023

March 15, 2023

Yesterday we posted a short article that gives a primer on this project: https://www.icann.org/en/blogs/details/how-time-zones-are-coordinated-13-03… It is also being circulated to attendees to our major conference being held in Mexico this week. An objective in posting this is to better raise awareness with policy makers to plan time zone rule changes well in advance so that changes can be thoroughly disseminated. There are many government representatives from around the world at this Mexico meeting so hopefully this can contribute to spreading the word. kim

3 2

Re: [tz] Morocco : Ramdan Time Change 2021
by Paul Eggert March 15, 2023

March 15, 2023

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

DST Change in Egypt
by Ahmed Hanafy March 15, 2023

March 15, 2023

Dear Team, Seeking your support to publish an updated package which contains the new update for EGYPT DST as it will return back as mentioned on below links. Adjusting the clock - Egypt - Al-Ahram Weekly - Ahram Online<https://english.ahram.org.eg/NewsContent/50/1201/491316/AlAhram-Weekly/Egyp…> Egypt Reintroduces DST to Save Energy (timeanddate.com)<https://www.timeanddate.com/news/time/dst-egypt-2023.html> DST News - Egypt to return of Summer Time daylight saving time in 2023 (worldtimezone.com)<https://www.worldtimezone.com/dst_news/dst_news_egypt11.html> [cid:image001.png@01D9577D.AF17A070] Thanks BR [https://mediabank.ericsson.net/internet-media/Email_logo_Ericsson.png]<https://www.ericsson.com/> Ahmed Hanafy Customer Technical Manager S&R MMEA NEW S&R CU SSE Mobile: +201116114054 ahmed.hanafy(a)ericsson.com Ericsson Km 28 Cairo-Alex desert road, Smart Village B124 27-12577, Al Jizah Giza Egypt ericsson.com<https://www.ericsson.com/> [https://mediabank.ericsson.net/internet-media/Email_Message.gif]<https://www.ericsson.com/current_campaign> Our commitment to Technology for Good<https://www.ericsson.com/thecompany/sustainability-corporateresponsibility> and Diversity and Inclusion<https://www.ericsson.com/thecompany/diversity-inclusion> contributes to positive change. Follow us on: Facebook<https://www.facebook.com/ericsson> LinkedIn<https://www.linkedin.com/company/ericsson> Twitter<https://twitter.com/Ericsson> Legal entity:ERICSSON EGYPT LTD. registration number 16630, registered office in Cairo. This communication is confidential. Our email terms: www.ericsson.com/en/legal/privacy/email-disclaimer<https://www.ericsson.com/en/legal/privacy/email-disclaimer>

2 2

Timezone change announcement - Egypt
by Mohammed Amer (Skyvera Support) March 15, 2023

March 15, 2023

Hi Dears, this is to let you know that Egypt will return working with DST changes . the change will be done on the Last Friday of April 28th 2023 . I m sharing the wikipedia article : https://en.wikipedia.org/wiki/Daylight_saving_time_in_Egypt Reaching out to you to update tzdata package. Best Regards, Mohammed Amer Conversation ID: 205380e6-c356-11ed-bd31-cecd37de1d19 205380e6-c356-11ed-bd31-cecd37de1d19 f047743

1 0

DST Change in Egypt April from GMT+2 to GMT+3
by Amir Ayad March 15, 2023

March 15, 2023

Dear Team, Hope everything is great. Kindly need your support to provide us with an updated TZ package as our Government in Egypt recently declared to start applying DST timings starting from last week in April till last week in October which will impact many Ericsson charging nodes. Accordingly we need this package the soonest to start implementing on our nodes. Thanks in advance for your usual support. Best Regards, [https://www.ericsson.com]<https://www.ericsson.com/> Amir Ayad Senior Support Engineer MMEA MS NEW SSE MOBINIL 2LO Mobile: +201284336575 amir.ayad(a)ericsson.com<mailto:amir.ayad@ericsson.com> Ericsson Smart Village KM 28 Cairo/Alex Road, Bldg#86B 6580, Sixth of October City Egypt ericsson.com<https://www.ericsson.com/>

5 12

Mexico Time Change
by Neda Zaman March 14, 2023

March 14, 2023

Hello, I hope this email finds you and your team well. I wanted to inquire about the update to the rules for Mexico as they have announced they will not be following daylight saving's time as of this year. https://www.usnews.com/news/best-states/arizona/articles/2022-10-26/mexico-… Will this be reflected on the tz database? Thank you, Neda Zaman | Product Manager | UKG Ultimate Kronos Group T: 678 658 5435<tel:678%20658%205435> 400 Galleria Pkwy, Atlanta, GA, 30339, Suite 800 UKG.com<https://www.ukg.com/> | Our purpose is people. Follow UKG: LinkedIn<https://www.linkedin.com/company/ukg> | YouTube<https://www.youtube.com/channel/UCJZMTrZOfBMqMwuL4tfEsmQ> | Twitter<https://twitter.com/UKGInc>

2 1

Wrong timezone
by Minu Shie March 14, 2023

March 14, 2023

Hi, I've checked the sites that are currently using your database and all of them have the wrong timezone for Valle Hermoso, Tamaulipas, México. Which should be the same as Matamoros, Tamaulipas, México. (America/Matamoros) instead of (America/Monterrey). Source from the Government official diary in Article 5, paragraph I: https://dof.gob.mx/nota_detalle.php?codigo=5670045&fecha=28/10/2022#gsc.tab…

2 1

Building tz with gcc-13
by Martin Jansa March 13, 2023

March 13, 2023

Hello, I was building tz with gcc-13 and noticed that without explicit -std=c2x it fails to build 2022g version with: ``` zic.c:462:1: warning: ‘noreturn’ attribute ignored [-Wattributes] 462 | static ATTRIBUTE_NORETURN void | ^~~~~~ zic.c:462:27: error: expected identifier or ‘(’ before ‘void’ 462 | static ATTRIBUTE_NORETURN void | ^~~~ ``` The last code change on github in this are was: https://github.com/eggert/tz/commit/dbfcefe0c129e36e8c5acbcedf1400c1b486d962 It builds fine for me with gcc-12 without -std: ``` __STDC_VERSION__ = 201710 __has_c_attribute(noreturn) = 0 ``` and with -std=c2x: ``` __STDC_VERSION__ = 202000 __has_c_attribute(noreturn) = 0 __STRICT_ANSI__ ``` but with gcc-13 it builds only with explicit -std=c2x: ``` __STDC_VERSION__ = 202000 __has_c_attribute(noreturn) = 202202 __STRICT_ANSI__ ``` Maybe because __has_c_attribute(noreturn) returns 202202 even when __STDC_VERSION__ doesn't accept it yet? ``` __STDC_VERSION__ = 201710 __has_c_attribute(noreturn) = 202202 ``` >From https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2764.pdf it's not clear to me when exactly [[noreturn]] can be used. It says only this about the value `Drafting note: The value used for __has_c_attribute is a placeholder that is to be replaced by the editors with the year and month the proposal is accepted into the working draft.` Is it a bug in gcc or should it be handled somehow by private.h? Thanks

4 4

Fwd: New Version Notification for draft-murchison-rfc8536bis-07.txt
by Ken Murchison March 13, 2023

March 13, 2023

FYI. -------- Forwarded Message -------- Subject: New Version Notification for draft-murchison-rfc8536bis-07.txt Date: Mon, 13 Mar 2023 06:44:33 -0700 From: internet-drafts(a)ietf.org To: Arthur David Olson <arthurdavidolson(a)gmail.com>, Arthur Olson <arthurdavidolson(a)gmail.com>, Kenneth Murchison <murch(a)fastmailteam.com>, Paul Eggert <eggert(a)cs.ucla.edu> A new version of I-D, draft-murchison-rfc8536bis-07.txt has been successfully submitted by Kenneth Murchison and posted to the IETF repository. Name: draft-murchison-rfc8536bis Revision: 07 Title: The Time Zone Information Format (TZif) Document date: 2023-03-13 Group: Individual Submission Pages: 48 URL: https://www.ietf.org/archive/id/draft-murchison-rfc8536bis-07.txt Status: https://datatracker.ietf.org/doc/draft-murchison-rfc8536bis/ Html: https://www.ietf.org/archive/id/draft-murchison-rfc8536bis-07.html Htmlized: https://datatracker.ietf.org/doc/html/draft-murchison-rfc8536bis Diff: https://author-tools.ietf.org/iddiff?url2=draft-murchison-rfc8536bis-07 Abstract: This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined. This document replaces and obsoletes RFC 8536. The IETF Secretariat

1 0

two distinct limits on time zone abbreviation length in tzcode?
by Paul Eggert March 13, 2023

March 13, 2023

I just noticed that tzcode has two distinct limits on time zone abbreviation length. One is MY_TZNAME_MAX (which is 255 on GNU/Linux and I expect smaller on other platforms); the other is TZ_ABBR_MAX_LEN (which is always 16). The latter limit was introduced in 2005, here: https://mm.icann.org/pipermail/tz/2005-May/013037.html These two distinct limits can lead to confusing behavior. For example, on GNU/Linux if you compile and build tzcode date you can see this behavior: $ TZ=ABCDEFGHIJKLMNOPQ4 date Sun Mar 5 07:21:41 ABCDEFGHIJKLMNOP 2023 $ TZ=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4 date Sun Mar 5 11:22:05 UTC 2023 In the first example, the "Q" is silently dropped (it's one more than the 16-byte limit), whereas in the second example, the entire TZ string is ignored and UTC is silently substituted. I'm thinking of changing the code so that there's just one limit, presumably the higher one, so that we don't get the confusing behavior noted above. Comments welcome.

1 1