- tz - lists.iana.org

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

Tzdb and the Sunshine Protection Act
by Brooks Harris March 5, 2023

March 5, 2023

You've seen the Sunshine Protection Act is back: Congress to consider making daylight saving time permanent https://www.axios.com/2023/03/02/daylight-saving-time-change-permanent-cong… As I read the law it would shift STDOFF by an hour, for example, America/New_York would move to -04:00 STDOFF, essentially moving "Eastern Time" into the Atlantic time zone. Historically tzdb has honored the laws as faithfully as possible so that might be the right approach. But it seems to me this would be technically disruptive, necessitating a great deal of careful modification of existing implementations. The other method is to shift DST rules to "permanent" DST. The law might arguably be interpreted this way. That might be less disruptive and leave the option of returning to DST when its no longer "permanent", as happened in the 1970s. There are many arguments for going to "permanent standard time" instead. One reason not mentioned is that it would be technically much easier and less disruptive. How will tzdb manage this?

11 22