December 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

Questions on tzname and tm_zone
by Patrik Lantto 31 Dec '22

31 Dec '22

Dear all, I have a few questions regarding how the tzdb code handles tzname and tm_zone: * The define HAVE_TZNAME have three different "settings"; 0 if tzname is not supported, 1 to support tzname defined by the system library and 2 to support and define tzname. In the code though, when defining tzname it also adds the value of TZ_TIME_T which reduces the options. Basically, if time_tz is defined to another datatype that time_t, tzname cannot be defined by the system library since setting HAVE_TZNAME to 1 would still define tzname (around line 195 of localtime.c). Is there a reason for this behaviour (which is also similar for USG_COMPAT)? In my platform we define a new 64 bit datatype, but would still need tzname as defined by the system library. * In case of an invalid timezone, the behaviour of tzname and tm_zone behaves differently; tzname would be set to WILDABBR (which is possible to define), but if localtime is called tm_zone will be set to "UTC" while if gmtime is called, tm_zone is set to "-00" and if offtime is called (with a non-0 offset) tm_zone is WILDABBR. It seems somewhat inconsistent, so is this by design? * The way tzname is updated (in settzname) in settzname is that it first set tzname[0] and tzname[1] to either WILDABBR or UTC, and then possibly update with the correct names. While tzname is not considered thread safe, this way writing to tzname twice means that even call to tzset with the same timezone could affect other threads reading tzname. Not a huge risk, but still possible. Is this something to consider in the implementation? * Since tzname is not thread safe, and due to the way tm_zone is handled it is somewhat hard to detect if a TZ string is valid or not. Is there a recommended way to detect an invalid string? Best regards, Patrik Lantto -- Patrik Lantto - patrik.lantto(a)wisi.se - +46 13 210918

2 1

[PROPOSED] Support leap-seconds.list tombstone
by Paul Eggert 22 Dec '22

22 Dec '22

From: Paul Eggert <eggert@trombone> This change looks forward to the possibility of leap seconds being discontinued by 2035. If and when that happens, the expiration date on the leap-seconds.list file is likely to stop being maintained, as there will be no need to issue new versions of leap-seconds.list every six months. Although the details have not been decided, for now assume that the last edition of leap-seconds.list will simply lack an expiration-date line. * leapseconds.awk: If the input lacks an expiration line like ‘#@ 3896899200’, do not treat it as if ‘#@ 0’ were present, as that would mean an expiration date of 1900-01-01. Instead, do not output an expiration date; just output a comment saying that there is no expiration date. Similarly for update dates and input lacking lines like ’#$ 3676924800’. --- NEWS | 3 +++ leapseconds.awk | 50 ++++++++++++++++++++++++++++++------------------- 2 files changed, 34 insertions(+), 19 deletions(-) diff --git a/NEWS b/NEWS index 9ac3367..5510823 100644 --- a/NEWS +++ b/NEWS @@ -42,6 +42,9 @@ Unreleased, experimental changes 'restrict' keyword consistently with their documentation. This may allow future optimizations. + leapseconds.awk can now process a leap seconds file that never + expires; this might be useful if leap seconds are discontinued. + Changes to commentary Note that leap seconds are planned to be discontinued by 2035. diff --git a/leapseconds.awk b/leapseconds.awk index b6c48bc..7d2556b 100644 --- a/leapseconds.awk +++ b/leapseconds.awk @@ -104,18 +104,23 @@ BEGIN { } END { - sstamp_to_ymdhMs(expires, ss_NTP) - print "" - print "# UTC timestamp when this leap second list expires." - print "# Any additional leap seconds will come after this." - if (! EXPIRES_LINE) { - print "# This Expires line is commented out for now," - print "# so that pre-2020a zic implementations do not reject this file." + + if (expires) { + sstamp_to_ymdhMs(expires, ss_NTP) + + print "# UTC timestamp when this leap second list expires." + print "# Any additional leap seconds will come after this." + if (! EXPIRES_LINE) { + print "# This Expires line is commented out for now," + print "# so that pre-2020a zic implementations do not reject this file." + } + printf "%sExpires %.4d\t%s\t%.2d\t%.2d:%.2d:%.2d\n", \ + EXPIRES_LINE ? "" : "#", \ + ss_year, monthabbr[ss_month], ss_mday, ss_hour, ss_min, ss_sec + } else { + print "# (No Expires line, since the expires time is unknown.)" } - printf "%sExpires %.4d\t%s\t%.2d\t%.2d:%.2d:%.2d\n", \ - EXPIRES_LINE ? "" : "#", \ - ss_year, monthabbr[ss_month], ss_mday, ss_hour, ss_min, ss_sec # The difference between the NTP and POSIX epochs is 70 years # (including 17 leap days), each 24 hours of 60 minutes of 60 @@ -124,15 +129,22 @@ END { print "" print "# POSIX timestamps for the data in this file:" - sstamp_to_ymdhMs(updated, ss_NTP) - printf "#updated %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \ - updated - epoch_minus_NTP, \ - ss_year, ss_month, ss_mday, ss_hour, ss_min, ss_sec - sstamp_to_ymdhMs(expires, ss_NTP) - printf "#expires %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \ - expires - epoch_minus_NTP, \ - ss_year, ss_month, ss_mday, ss_hour, ss_min, ss_sec - + if (updated) { + sstamp_to_ymdhMs(updated, ss_NTP) + printf "#updated %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \ + updated - epoch_minus_NTP, \ + ss_year, ss_month, ss_mday, ss_hour, ss_min, ss_sec + } else { + print "#(updated time unknown)" + } + if (expires) { + sstamp_to_ymdhMs(expires, ss_NTP) + printf "#expires %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \ + expires - epoch_minus_NTP, \ + ss_year, ss_month, ss_mday, ss_hour, ss_min, ss_sec + } else { + print "#(expires time unknown)" + } printf "\n%s", last_lines } -- 2.38.1

1 0

Re: [tz] [PROPOSED] Mention the planned obsolescence of leap seconds
by Brian Inglis 22 Dec '22

22 Dec '22

On 2022-12-20 17:25, Paul Eggert via tz wrote: > + Changes to commentary > + Note that leap seconds are planned to be discontinued by 2035. > + This affects time stamps during the leap second era (1972–2035). > +Leap seconds were introduced in 1972 to accommodate the > +difference between atomic time and the less-regular rotation of the earth. > +Unfortunately they caused so many problems with civil Civil (e.g. legal etc.) time keeping is not the problem, it is mainly proprietary computer systems and applications, not adequately programmed to deal with the realities of time keeping. > +timekeeping that they > +are <a href="https://www.bipm.org/en/cgpm-2022/resolution-4">planned > +to be discontinued by 2035</a>, with some as-yet-undetermined > +mechanism replacing them, perhaps after the year 2135. > +Despite their impending obsolescence, a record of leap seconds is still > +needed to resolve timestamps from 1972 through 2035. I would expect astronomers and physicists to have divergent views, but both use software which handles varieties of time bases, scales, and conversions. It seems likely that other scientists and disciplines with time concerns would line up behind one or the other, depending on whether their focus is civil, geocentric, or longer term in some way, or more artificial on accuracy, calibration, precision or other short term characteristics. > <a href="https://www.ucolick.org/~sla/leapsecs/"><abbr>UTC</abbr> > might be redefined > without Leap Seconds</a> gives pointers on this > +contentious issue. > +The General Conference on Weights and Measures > +<a href="https://www.bipm.org/en/cgpm-2022/resolution-4">voted in 2022</a> > +to discontinue the use of leap seconds by 2035, replacing them with an > +as-yet-undetermined scheme some time after the year 2135. Expect every lawyer, in any case involving time stamped records, to jump on the technicality of any significant deviation of time keeping from solar time, which is the legal basis in most English common law jurisdictions, possibly also in some continental code and Scandinavian/Nordic jurisdictions e.g. Denmark: https://www.dr.dk/nyheder/indland/uret-paa-din-telefon-viser-en-ulovlig-tid https://www-dr-dk.translate.goog/nyheder/indland/uret-paa-din-telefon-viser… -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

1 0

DST in the news
by Arthur David Olson 22 Dec '22

22 Dec '22

A 538 piece on the merits and demerits of permanent standard time and permanent daylight time. https://projects.fivethirtyeight.com/daylight-saving-time/ --ado

1 0

[PROPOSED] Document deprecation of ctime, asctime.
by Paul Eggert 21 Dec '22

21 Dec '22

--- newctime.3 | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/newctime.3 b/newctime.3 index e25d841..2790c81 100644 --- a/newctime.3 +++ b/newctime.3 @@ -11,13 +11,13 @@ asctime, ctime, difftime, gmtime, localtime, mktime \- convert date and time .PP .BR "extern char *tzname[];" " /\(** (optional) \(**/" .PP -.B char *ctime(time_t const *clock); +.B [[deprecated]] char *ctime(time_t const *clock); .PP .B char *ctime_r(time_t const *clock, char *buf); .PP .B double difftime(time_t time1, time_t time0); .PP -.B char *asctime(struct tm const *tm); +.B [[deprecated]] char *asctime(struct tm const *tm); .PP .B "char *asctime_r(struct tm const *restrict tm," .B " char *restrict result);" @@ -91,6 +91,15 @@ introduction of UTC and are some other flavor of Universal Time (UT). Some implementations support leap seconds, in contradiction to POSIX. .PP The +.B ctime +function is deprecated starting in C23. +Callers can use +.B localtime_r +and +.B strftime +instead. +.PP +The .B localtime and .B gmtime @@ -128,6 +137,10 @@ converts a time value contained in a structure to a string, as shown in the above example, and returns a pointer to the string. +This function is deprecated starting in C23. +Callers can use +.B strftime +instead. .PP The .B mktime -- 2.38.1

1 0

Windows build failures
by Manuela Friedrich 21 Dec '22

21 Dec '22

Hello Paul, I noticed new Windows build failures with the latest tz code from git. Hopefully you can shed some light on these. Error 1 d:\iana\tmp\private.h(704): error C2373: 'restrict': redefinition; different type modifiers d:\iana\tmp\private.h(704): note: see declaration of 'restrict' d:\iana\tmp\private.h(780): error C2373: 'restrict': redefinition; different type modifiers d:\iana\tmp\private.h(780): note: see declaration of 'restrict' d:\iana\tmp\private.h(781): error C2371: 'restrict': redefinition; different basic types d:\iana\tmp\private.h(780): note: see declaration of 'restrict' Error 2 zic.c(154): error C2146: syntax error: missing ')' before identifier 'file' zic.c(154): error C2061: syntax error: identifier 'file' zic.c(154): error C2059: syntax error: ';' zic.c(154): error C2059: syntax error: ',' zic.c(154): error C2059: syntax error: ')' Thank you! Kind Regards Manuela Friedrich

2 5