- tz - lists.iana.org

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

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

March 10, 2023

All, Here is the latest update to the TZif specification. Please give this a review and let us know if there are any errors or omissions. I'd like to start the process of getting this published as a new RFC, which will obsolete RFC 8536. -------- Forwarded Message -------- Subject: New Version Notification for draft-murchison-rfc8536bis-06.txt Date: Tue, 07 Mar 2023 07:00:48 -0800 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-06.txt has been successfully submitted by Kenneth Murchison and posted to the IETF repository. Name: draft-murchison-rfc8536bis Revision: 06 Title: The Time Zone Information Format (TZif) Document date: 2023-03-07 Group: Individual Submission Pages: 46 URL: https://www.ietf.org/archive/id/draft-murchison-rfc8536bis-06.txt Status: https://datatracker.ietf.org/doc/draft-murchison-rfc8536bis/ Html: https://www.ietf.org/archive/id/draft-murchison-rfc8536bis-06.html Htmlized: https://datatracker.ietf.org/doc/html/draft-murchison-rfc8536bis Diff: https://author-tools.ietf.org/iddiff?url2=draft-murchison-rfc8536bis-06 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

10 22

Questions About tz database
by Jaime Suazo Vacca March 9, 2023

March 9, 2023

Hello !!! Is this the right place to ask if the latest Chilean tz is going to be added to the database? Currently is not there and we have a tz change on April 2023 Thanks for any information you can share with us Best regards/Saludos Cordiales, Jaime Suazo Mining Techn. Impl. Spec. Caterpillar Caterpillar: Confidential Green

2 4

[PROPOSED] Improve tzselect explanation
by Paul Eggert March 6, 2023

March 6, 2023

* tzselect.ksh: Improve quality of "Based on the following information:" note when the user selected a time first. --- tzselect.ksh | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/tzselect.ksh b/tzselect.ksh index 41180ae9..b8f64077 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -551,6 +551,7 @@ while echo >&2 'Please select a country' \ 'whose clocks agree with yours.' doselect $countries + country_result=$select_result country=$select_result;; *) country=$countries @@ -653,12 +654,13 @@ Universal Time is now: $UTdate." echo >&2 "" echo >&2 "Based on the following information:" echo >&2 "" - case $time%$country%$region%$coord in + case $time%$country_result%$region%$coord in ?*%?*%?*%) - say >&2 " $time$newline $country$newline $region";; - ?*%?*%%) say >&2 " $time$newline $country";; - %?*%?*%) say >&2 " $country$newline $region";; - %?*%%) say >&2 " $country";; + say >&2 " $time$newline $country_result$newline $region";; + ?*%?*%%|?*%%?*%) say >&2 " $time$newline $country_result$region";; + ?*%%%) say >&2 " $time";; + %?*%?*%) say >&2 " $country_result$newline $region";; + %?*%%) say >&2 " $country_result";; %%?*%?*) say >&2 " coord $coord$newline $region";; %%%?*) say >&2 " coord $coord";; *) say >&2 " TZ='$TZ'" -- 2.37.2

1 0