- tz - lists.iana.org

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

DST changes to Egypt's time starting from 28/April/2023
by Moustafa Hammouda March 12, 2023

March 12, 2023

Greetings, I would like to inform you about some planned changes to the DST in Egypt [1]. These changes were officially announced by the Egyptian government. I'm posting this excerpt and it's translation from the official government based newspaper (Ahram): ووافق مجلس الوزراء خلال اجتماعه اليوم، برئاسة الدكتور مصطفى مدبولي، على عدة > قرارات، هي: > - وافق مجلس الوزراء على مشروع قانون في شأن عودة العمل بنظام التوقيت الصيفي > . > وجاء نص مشروع القانون كالتالي: "اعتباراً من الجمعة الأخيرة من شهر أبريل، > حتى نهاية يوم الخميس الأخير من شهر أكتوبر من كل عام ميلادي، تكون الساعة > القانونية في جمهورية مصر العربية، هي الساعة بحسب التوقيت المُتبع، مُقدمة > بمقدار ستين دقيقة". *Translation:* During its meeting today, headed by Dr. Mostafa Madbouly, the Council of Ministers approved several decisions, which are: - The Council of Ministers approved a draft law regarding the return of the summer time system. The text of the draft law came as follows: “From the last Friday of April until the end of the last Thursday of October of each Gregorian year, the legal hour in the Arab Republic of Egypt is the hour according to the time followed, advanced by sixty minutes.” [1] https://gate.ahram.org.eg/News/4162139.aspx [2] https://time.is/time_zone_news/egypt_brings_back_dst [3] https://www.timeanddate.com/news/time/dst-egypt-2023.html [4] https://www.economist.com/middle-east-and-africa/2023/03/09/fiddling-with-e… [5] https://www.reuters.com/world/africa/egypt-use-daylight-saving-time-again-b… -- Best Regards, Moustafa Harbi Senior Technical Account Manager, Red Hat FZ LLC Red Hat Middle East, Turkey & Africa <https://www.redhat.com/> Office Park Building, Block A, Floor 4 PO Box 502579, Dubai, UAE mharbi(a)redhat.com M: +971585935441 <https://red.ht/sig>

1 0

Leap hour smearing...
by Arthur David Olson March 12, 2023

March 12, 2023

...on an outdoor clock in my home town of Takoma Park, Maryland. The clock has a weird intermittent-sweep minute hand. It took about eight minutes to get from 2:00 to 3:08. @dashdashado https://youtu.be/XeVLyyBSOT8

1 0

Recommendations to governments about time zone update notice period and format
by Neil Fuller March 10, 2023

March 10, 2023

The latest short-notice time zone change from Egypt, so soon after the Mexico changes, made me wonder... Would it be useful to have a canonical thread or set of links in the TZDB docs to point to for user-facing "Why hasn't my device updated?" or government-facing "Why didn't our legislation change reach citizen's devices in time?" -type questions? For example, here are recommendations/policy I know of for a couple of widely-used operating systems / platforms: Android: https://source.android.com/docs/core/connect/time/time-zone-policy-recommen… (this is relatively new) Windows: https://learn.microsoft.com/en-us/troubleshoot/windows-client/system-manage… Maybe these could be collated and extended for other consumers of TZDB. ------- I vaguely remembered there being something in the TZDB docs that says something along these lines [*] but I couldn't find it and might be getting confused with threads on the mailing list. I don't honestly expect having it written down to make a lot of difference, but the regular lack of notice and confusion about what *exactly* governments have changed makes me think there *could* be a set of recommendations. Then, governments that *want* to do the right thing could then know what to provide / expect and plan accordingly, and ones that don't try can be easily informed why things didn't work out like they may have expected. Thanks, Neil. [*] e.g. maybe something like "Many downstream users of the TZDB wait for an official TZDB release before they will produce an update to time zone behavior in consumer devices and software products. After TZDB has been updated, various parties have to perform their own integration, testing, and rollout of an update before users will see changes. These updates can be expensive, e.g. for the QA process itself and the network costs for updates to each TZDB copy. Updates may be batched with other updates and take substantial time to reach users after the TZDB release. Updates will require that affected products have a suitable update mechanism in place and are still supported." -- Google UK Limited Registered Office: 6 Pancras Square, London, N1C 4AG Registered in England Number: 3977902

4 5

Re: [tz] mandoc(1) warning in tzfile(5) regarding //
by Paul Eggert March 10, 2023

March 10, 2023

On 3/8/23 14:15, Alejandro Colomar wrote: > That patch looks good to me. If you use these: > > Reviewed-by: Alejandro Colomar <alx(a)kernel.org> Oh, we don't use those in tzdb; instead your name is mentioned in the commit message. I installed it that way. > I suggest using the project name without a > version. How about the following? > > .TH tzfile 5 "" tzdb > > (or alternatively:) > > .TH tzfile 5 "" "Time Zone Database" Yes, that should work. I installed the attached proposed patch into the tzdb development repository. Feel free to migrate this into man-pages at your convenience. No rush of course. >> I've been reluctant to do that upstream since I expect each >> downstream user has its own format for comments regarding licensing, >> SBOM, SSDF, SCA, and so forth (and if you don't know what those acronyms >> mean then I envy you :-). > > I don't :-) https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecur…

2 1