- tz - lists.iana.org

NIST URLs for leap-seconds.list in leapseconds.awk
by PoolMUC＠web.de Jan. 10, 2024

Jan. 10, 2024

(apologies for earlier HTML mail, same message again in plain text (hopefully...)) Hi, After recent updates to leapseconds.awk to include IERS as a source for leap-seconds.list, one URL given for the file at NIST still is ftp://ftp.nist.gov/pub/time/leap-seconds.list: print "# This file is generated automatically from the data in the public-domain" print "# NIST/IERS format leap-seconds.list file, which can be copied from" print "# <https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list>" print "# or, in a variant with different comments, from" print "# <ftp://ftp.nist.gov/pub/time/leap-seconds.list>" print "# or <ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list>." However, at least for me, and at this time, the hostname ftp.nist.gov does not resolve. ftp.boulder.nist.gov does resolve. If others are seeing the same, and the condition persists, maybe the URL based on ftp.nist.gov should be removed. Thanks!

1 0

Fwd: Bulletin C number 67
by Martin Burnicki Jan. 9, 2024

Jan. 9, 2024

Bulletin C number 67 is available, see also: https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat At the same time, a new NTP leap second file has been made available by IERS (directory listing): https://hpiers.obspm.fr/iers/bul/bulc/ntp/ New file: https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.3913697179 As expected, no leap second is scheduled for the end of June 2024, but the expiration date of the file has been updated. As far as I see, the file also includes the changes recently discussed on this list, regarding a copyright info and some cosmetic changes. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki(a)meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Natalie Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com

2 1

2023d zdump with "min" year rule?
by Yoshito Umaoka Jan. 8, 2024

Jan. 8, 2024

Dear TZ Database maintainers, We (Unicode ICU project) preserve time zones deprecated in the TZ database. We keep old systemv file and include these zones in our library. For example, # SystemV time zones. # IANA tzdb file 'systemv' file has these SystemV/* zones commented out up to 2020a. # 'systemv' file was removed in 2020b. We keep them in this supplemental zone data # file for compatibility purpose. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule SystemV min 1973 - Apr lastSun 2:00 1:00 D Rule SystemV min 1973 - Oct lastSun 2:00 0 S Rule SystemV 1974 only - Jan 6 2:00 1:00 D Rule SystemV 1974 only - Nov lastSun 2:00 0 S Rule SystemV 1975 only - Feb 23 2:00 1:00 D Rule SystemV 1975 only - Oct lastSun 2:00 0 S Rule SystemV 1976 max - Apr lastSun 2:00 1:00 D Rule SystemV 1976 max - Oct lastSun 2:00 0 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone SystemV/AST4ADT -4:00 SystemV A%sT Zone SystemV/EST5EDT -5:00 SystemV E%sT Zone SystemV/CST6CDT -6:00 SystemV C%sT Zone SystemV/MST7MDT -7:00 SystemV M%sT Zone SystemV/PST8PDT -8:00 SystemV P%sT Zone SystemV/YST9YDT -9:00 SystemV Y%sT Zone SystemV/AST4 -4:00 - AST Zone SystemV/EST5 -5:00 - EST Zone SystemV/CST6 -6:00 - CST Zone SystemV/MST7 -7:00 - MST Zone SystemV/PST8 -8:00 - PST Zone SystemV/YST9 -9:00 - YST Zone SystemV/HST10 -10:00 - HST ICU data build feeds the extra zone file including above to zic, then run zdump to emit zone offset transitions. Then compare the output with the equivalent output produced by ICU library code. I’m currently working on TZ database 2023d and found this check is failing for SystemV/* with daylight saving time rule. All other zones work fine. With zdump in 2023d, all transitions before 1970 are not reported. For example: $ zdump -c 1900,1975 -V SystemV/AST4ADT emits the output below: SystemV/AST4ADT Sun Apr 26 05:59:59 1970 UT = Sun Apr 26 01:59:59 1970 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Apr 26 06:00:00 1970 UT = Sun Apr 26 03:00:00 1970 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 25 04:59:59 1970 UT = Sun Oct 25 01:59:59 1970 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 25 05:00:00 1970 UT = Sun Oct 25 01:00:00 1970 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Apr 25 05:59:59 1971 UT = Sun Apr 25 01:59:59 1971 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Apr 25 06:00:00 1971 UT = Sun Apr 25 03:00:00 1971 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 31 04:59:59 1971 UT = Sun Oct 31 01:59:59 1971 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 31 05:00:00 1971 UT = Sun Oct 31 01:00:00 1971 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Apr 30 05:59:59 1972 UT = Sun Apr 30 01:59:59 1972 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Apr 30 06:00:00 1972 UT = Sun Apr 30 03:00:00 1972 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 29 04:59:59 1972 UT = Sun Oct 29 01:59:59 1972 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 29 05:00:00 1972 UT = Sun Oct 29 01:00:00 1972 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Apr 29 05:59:59 1973 UT = Sun Apr 29 01:59:59 1973 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Apr 29 06:00:00 1973 UT = Sun Apr 29 03:00:00 1973 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 28 04:59:59 1973 UT = Sun Oct 28 01:59:59 1973 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 28 05:00:00 1973 UT = Sun Oct 28 01:00:00 1973 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Jan 6 05:59:59 1974 UT = Sun Jan 6 01:59:59 1974 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Jan 6 06:00:00 1974 UT = Sun Jan 6 03:00:00 1974 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Nov 24 04:59:59 1974 UT = Sun Nov 24 01:59:59 1974 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Nov 24 05:00:00 1974 UT = Sun Nov 24 01:00:00 1974 AST isdst=0 gmtoff=-14400 This is not a problem with 2023c. 2023c emits transitions starting year 1900 (the first year in the range) to 1975. I think these are only zones using rule line with “min” year rule. I suspect there is a regression bug in zdump when such rule is used. -Yoshito Umaoka

2 2

Ministry of Digital Development and Communications, the Government of Mongolia
by fr Jan. 7, 2024

Jan. 7, 2024

Dear Sir/Ma'am, As we sent an inquiry regarding the switching time to the regular summer time matter earlier, could you please provide us some recommendations on below. The Government of Mongolia is planning to switch to the regular summer time from 22-26 March, 2024. Currently, the discussions are made within the Government as well as at the Parliament. We expect that final decision will be made in the October. Therefore, is it possible to arrange the switching process in the next 5 months? Is there any extraordinary cases like us or not? Or shall we make our changes in the September 2024? Thank you for your kind consideration in advance and hope to hear from you soon. Sincerely, Ms. Ariuntuul --- Foreign Cooperation Division Ministry of Digital Development and Communications The Government of Mongolia Tel: +976 51 260636 www.mddc.gov.mn

4 4

Possible clarification to the tzalloc() documentation
by Guy Harris Jan. 5, 2024

Jan. 5, 2024

The newtzset.3 man page says The tzalloc function allocates and returns a timezone object described by TZ. If TZ is not a valid timezone description, or if the object cannot be allocated, tzalloc returns a null pointer and sets errno. This doesn't explicitly say that TZ == NULL amounts to "not a valid timezone description", nor does it explicitly say that implementation-defined default timezone information is used. (The latter is the behavior the code implements.) It does say If TZ is null, the best available approximation to local (wall clock) time, as specified by the tzfile(5)-format file localtime in the system time conversion information directory, is used. If TZ is the empty string, UT is used, with the abbreviation "UTC" and without leap second correction; please see newctime(3) for more about UT, UTC, and leap seconds. If TZ is nonnull and nonempty: if the value begins with a colon, it is used as a pathname of a file from which to read the time conversion information; if the value does not begin with a colon, it is first used as the pathname of a file from which to read the time conversion information, and, if that file cannot be read, is used directly as a specification of the time conversion information. after describing taser: The tzset function acts like tzalloc(getenv("TZ")), except it saves any resulting timezone object into internal storage that is accessed by localtime, localtime_r, and mktime. The anonymous shared timezone object is freed by the next call to tzset. If the implied call to tzalloc fails, tzset falls back on Universal Time (UT). but it might be clearer if the paragraph about tzset followed the "If TZ is..." text. Perhaps the "If TZ is not a valid timezone description, or..." text should immediacy follow the "If TZ is..." text, e.g. The tzalloc function allocates and returns a timezone object described by TZ. If TZ is null, the best available approximation to local (wall clock) time, as specified by the tzfile(5)-format file localtime in the system time conversion information directory, is used. If TZ is the empty string, UT is used, with the abbreviation "UTC" and without leap second correction; please see newctime(3) for more about UT, UTC, and leap seconds. If TZ is nonnull and nonempty: if the value begins with a colon, it is used as a pathname of a file from which to read the time conversion information; if the value does not begin with a colon, it is first used as the pathname of a file from which to read the time conversion information, and, if that file cannot be read, is used directly as a specification of the time conversion information. In the latter case, if TZ is not a valid timezone description, tzalloc returns a null pointer and sets errno. If the object cannot be allocated, or if a file cannot be read, tzalloc returns a null pointer and sets errno. The tzset function acts like tzalloc(getenv("TZ")), except it saves any resulting timezone object into internal storage that is accessed by localtime, localtime_r, and mktime. The anonymous shared timezone object is freed by the next call to tzset. If the implied call to tzalloc fails, tzset falls back on Universal Time (UT). with, if necessary, text reminding people that, if TZ is not seen in the environment, tzalloc(getenv("TZ")) is equivalent to tzalloc(NULL), so "the best available approximation to local (wall clock) time..." is used.

2 1

[PROPOSED 1/3] Avoid expr in tzselect
by Paul Eggert Jan. 2, 2024

Jan. 2, 2024

* tzselect.ksh: Rewrite to not use the expr command. Various implementations have problems or dump core given unusual inputs, so to avoid these issues use awk or sh (which we need to use anyway) instead of using expr. --- tzselect.ksh | 32 ++++++++++++++++++++++---------- 1 file changed, 22 insertions(+), 10 deletions(-) diff --git a/tzselect.ksh b/tzselect.ksh index 2073bccd..cc58db03 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -40,6 +40,9 @@ REPORT_BUGS_TO=tz(a)iana.org # The substr avoids problems when VALUE is of the form X=Y and would be # misinterpreted as an assignment. +# This script does not want path expansion. +set -f + # Specify default values for environment variables if they are unset. : ${AWK=awk} : ${TZDIR=`pwd`} @@ -113,7 +116,8 @@ then else doselect() { # Field width of the prompt numbers. - select_width=`expr $# : '.*'` + print_nargs_length="BEGIN {print length(\"$#\");}" + select_width=`$AWK "$print_nargs_length"` select_i= @@ -124,14 +128,14 @@ else select_i=0 for select_word do - select_i=`expr $select_i + 1` + select_i=`$AWK "BEGIN { print $select_i + 1 }"` printf >&2 "%${select_width}d) %s\\n" $select_i "$select_word" done;; *[!0-9]*) echo >&2 'Please enter a number in range.';; *) if test 1 -le $select_i && test $select_i -le $#; then - shift `expr $select_i - 1` + shift `$AWK "BEGIN { print $select_i - 1 }"` select_result=$1 break fi @@ -165,7 +169,7 @@ do esac done -shift `expr $OPTIND - 1` +shift `$AWK "BEGIN { print $OPTIND - 1 }"` case $# in 0) ;; *) say >&2 "$0: $1: unknown argument"; exit 1 @@ -439,7 +443,12 @@ while continent=$select_result case $continent in Americas) continent=America;; - *" "*) continent=`expr "$continent" : '\''$[^ ]*$'\''` + *) + # Get the first word of $continent. Path expansion is disabled + # so this works even with "*", which should not happen. + IFS=" " + for continent in $continent ""; do break; done + IFS=$newline;; esac case $zonetabtype,$continent in zonenow,*) ;; @@ -746,15 +755,18 @@ while do TZdate=`LANG=C TZ="$TZ_for_date" date` UTdate=`LANG=C TZ=UTC0 date` - TZsec=`expr "$TZdate" : '.*:$[0-5][0-9]$'` - UTsec=`expr "$UTdate" : '.*:$[0-5][0-9]$'` - case $TZsec in - $UTsec) + if $AWK ' + function getsecs(d) { + return match(d, /.*:[0-5][0-9]/) ? substr(d, RLENGTH - 1, 2) : "" + } + BEGIN { exit getsecs(ARGV[1]) != getsecs(ARGV[2]) } + ' ="$TZdate" ="$UTdate" + then extra_info=" Selected time is now: $TZdate. Universal Time is now: $UTdate." break - esac + fi done -- 2.40.1

1 2

time zone versus time zone...
by Arthur David Olson Jan. 1, 2024

Jan. 1, 2024

...over time, per Google ngrams. The beginning of the (relative) rise of timezone predates the first 1986 release of the time zone package. @dashdashado https://books.google.com/ngrams/graph?content=time+zone%2Ctimezone&year_sta…

1 0

[PROPOSED 1/2] Comics update
by Paul Eggert Jan. 1, 2024

Jan. 1, 2024

Add xkcd’s “Daylight Saving Choice”, “Date Line” and “DateTime”, along with today’s Frazz and FoxTrot. Remove Dilbert, which had a bad link. --- tz-art.html | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/tz-art.html b/tz-art.html index e3be5f29..aa044313 100644 --- a/tz-art.html +++ b/tz-art.html @@ -507,7 +507,10 @@ along with the panels "<a href="https://xkcd.com/2050/">6/6 Time</a>" (2018-09-24), "<a href="https://xkcd.com/2092/">Consensus New Year</a>" (2018-12-31), "<a href="https://xkcd.com/2266/">Leap Smearing</a>" (2020-02-10), -and "<a href="https://xkcd.com/2594/">Consensus Time</a>" (2022-03-16). +"<a href="https://xkcd.com/2594/">Consensus Time</a>" (2022-03-16), +"<a href="https://xkcd.com/2846/">Daylight Saving Choice</a>" (2023-10-25), +"<a href="https://xkcd.com/2854/">Date Line</a>" (2023-11-13), +and "<a href="https://xkcd.com/2867/">DateTime</a>" (2023-12-13). The related book What If? has an entry "<a href="https://what-if.xkcd.com/26/">Leap Seconds</a>" (2012-12-31). </li> @@ -520,9 +523,13 @@ Before Swine (2016-11-06)</a>. Stonehenge is abandoned in <a href="https://www.gocomics.com/nonsequitur/2017/03/12">Non Sequitur (2017-03-12)</a>. +</li> <li> -The boss freaks out in <a -href="https://dilbert.com/strip/1998-03-14">Dilbert (1998-03-14)</a>. +Caulfield proposes changing clocks just once a year in +<a href="https://www.gocomics.com/frazz/2023/12/31">Frazz +(2023-12-31)</a>, while Peter and Jason go multi-lingual and -zonal in +<a href="https://www.gocomics.com/foxtrot/2023/12/31">FoxTrot +(the same day)</a>. </li> <li> Peppermint Patty: "What if the world comes to an end tonight, Marcie?" -- 2.40.1

1 1

Possible zic bug in far future calculations?
by Gilmore Davidson Dec. 30, 2023

Dec. 30, 2023

I was compiling the 2023d release for the Moment Timezone JS library and noticed some oddities in the diff of the generated files. A lot of tests are auto-generated from the data for each tzdb release, making sure the library correctly handles each transition defined in `zdump` output. For 2023d, a handful of zones in North America added a lot more transition tests after the year 2400. These transitions were apparently missing in earlier releases, and appear to have been fixed by commit 35c116b7 ("Fix zic bug with Palestine after 2075"), which makes sense. But a strange case I noticed is specific to `America/Ciudad_Juarez`. In 2023c its overall zdump output ended at 2422, not 2499 like other zones. In 2023d zdump does go to 2499, but there's now a weird set of transitions in 2422. Compiling zic/zdump for 2023c and getting the data for 2421-2423: $ /tmp/tz/2023c/git/zdump -V -c2421,2424 /tmp/tz/2023c/zic/America/Ciudad_Juarez /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Mar 14 08:59:59 2421 UT = Sun Mar 14 01:59:59 2421 MST isdst=0 gmtoff=-25200 /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Mar 14 09:00:00 2421 UT = Sun Mar 14 03:00:00 2421 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Nov 7 07:59:59 2421 UT = Sun Nov 7 01:59:59 2421 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Nov 7 08:00:00 2421 UT = Sun Nov 7 01:00:00 2421 MST isdst=0 gmtoff=-25200 /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Mar 13 08:59:59 2422 UT = Sun Mar 13 01:59:59 2422 MST isdst=0 gmtoff=-25200 /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Mar 13 09:00:00 2422 UT = Sun Mar 13 03:00:00 2422 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Nov 6 07:59:59 2422 UT = Sun Nov 6 01:59:59 2422 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Nov 6 08:00:00 2422 UT = Sun Nov 6 01:00:00 2422 MST isdst=0 gmtoff=-25200 Doing the same for 2023d: $ /tmp/tz/2023d/git/zdump -V -c2421,2424 /tmp/tz/2023d/zic/America/Ciudad_Juarez /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Mar 14 08:59:59 2421 UT = Sun Mar 14 01:59:59 2421 MST isdst=0 gmtoff=-25200 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Mar 14 09:00:00 2421 UT = Sun Mar 14 03:00:00 2421 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 7 07:59:59 2421 UT = Sun Nov 7 01:59:59 2421 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 7 08:00:00 2421 UT = Sun Nov 7 01:00:00 2421 MST isdst=0 gmtoff=-25200 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Mar 13 08:59:59 2422 UT = Sun Mar 13 01:59:59 2422 MST isdst=0 gmtoff=-25200 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Mar 13 09:00:00 2422 UT = Sun Mar 13 03:00:00 2422 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 6 07:59:59 2422 UT = Sun Nov 6 01:59:59 2422 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 6 08:00:00 2422 UT = Sun Nov 6 01:00:00 2422 MST isdst=0 gmtoff=-25200 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 6 08:00:00 2422 UT = Sun Nov 6 01:00:00 2422 MST isdst=0 gmtoff=-25200 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 6 08:00:01 2422 UT = Sun Nov 6 02:00:01 2422 CST isdst=0 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Wed Nov 30 05:59:59 2422 UT = Tue Nov 29 23:59:59 2422 CST isdst=0 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Wed Nov 30 06:00:00 2422 UT = Tue Nov 29 23:00:00 2422 MST isdst=0 gmtoff=-25200 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Mar 12 08:59:59 2423 UT = Sun Mar 12 01:59:59 2423 MST isdst=0 gmtoff=-25200 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Mar 12 09:00:00 2423 UT = Sun Mar 12 03:00:00 2423 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 5 07:59:59 2423 UT = Sun Nov 5 01:59:59 2423 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 5 08:00:00 2423 UT = Sun Nov 5 01:00:00 2423 MST isdst=0 gmtoff=-25200 Note that consecutive seconds on Nov 6 2422 go MDT -> MST -> CST, then back to MST on Nov 30. (For diagnostic purposes... I'm running these tests on macOS 14.2.1 with default `make` and `make install`, no extra flags.) I don't particularly care about (or believe) the accuracy of the data that far in the future, but the wonky transitions make me think there's a bug lurking in zic that might affect other transitions at some point, if the conditions are right. I found it interesting that the data previously cut off exactly 400 years after the zone's last defined "until" rule in `northamerica`. Digging further, the other zones that had incomplete data follow the same pattern: `America/Indiana/Petersberg` ended in 2407 (last defined "until" in 2007). `America/Indiana/Vincennes` the same. `America/North_Dakota/Belulah` ended in 2410 (last defined "until" in 2010). These other zones don't appear to have the same consecutive transition problem (i.e. they're not buggy any more), but the 400 year pattern is telling. Cheers, Gil

2 2

More than 2 transitions per year for Asia/Gaza & Hebron in 2068+
by Dave Rolsky Dec. 30, 2023

Dec. 30, 2023

Hi all, With the latest release (2023d) I'm seeing some surprising output from zdump for the Asia/Gaza & Asia/Hebron zones: $> zdump -v Asia/Hebron ... Asia/Hebron Fri Mar 23 23:59:59 2068 UT = Sat Mar 24 01:59:59 2068 EET isdst=0 gmtoff=7200 Asia/Hebron Sat Mar 24 00:00:00 2068 UT = Sat Mar 24 03:00:00 2068 EEST isdst=1 gmtoff=10800 Asia/Hebron Fri Oct 19 22:59:59 2068 UT = Sat Oct 20 01:59:59 2068 EEST isdst=1 gmtoff=10800 Asia/Hebron Fri Oct 19 23:00:00 2068 UT = Sat Oct 20 01:00:00 2068 EET isdst=0 gmtoff=7200 Asia/Hebron Fri Mar 29 23:59:59 2069 UT = Sat Mar 30 01:59:59 2069 EET isdst=0 gmtoff=7200 Asia/Hebron Sat Mar 30 00:00:00 2069 UT = Sat Mar 30 03:00:00 2069 EEST isdst=1 gmtoff=10800 Asia/Hebron Fri Oct 11 22:59:59 2069 UT = Sat Oct 12 01:59:59 2069 EEST isdst=1 gmtoff=10800 Asia/Hebron Fri Oct 11 23:00:00 2069 UT = Sat Oct 12 01:00:00 2069 EET isdst=0 gmtoff=7200 This pattern of >2 transitions per year continues from that year. Is this correct? It seems awfully weird. Cheers, Dave Rolsky http://blog.urth.org https://github.com/autarch

3 5

[tz-announce] 2023d release of tz code and data available
by Paul Eggert via tz-announce Dec. 22, 2023

Dec. 22, 2023

The 2023d release of the tz code and data is available. This release contains the following changes: Briefly: Ittoqqortoormiit, Greenland changes time zones on 2024-03-31. Vostok, Antarctica changed time zones on 2023-12-18. Casey, Antarctica changed time zones five times since 2020. Code and data fixes for Palestine timestamps starting in 2072. A new data file zonenow.tab for timestamps starting now. Changes to future timestamps Ittoqqortoormiit, Greenland (America/Scoresbysund) joins most of the rest of Greenland's timekeeping practice on 2024-03-31, by changing its time zone from -01/+00 to -02/-01 at the same moment as the spring-forward transition. Its clocks will therefore not spring forward as previously scheduled. The time zone change reverts to its common practice before 1981. Fix predictions for DST transitions in Palestine in 2072-2075, correcting a typo introduced in 2023a. Changes to past and future timestamps Vostok, Antarctica changed to +05 on 2023-12-18. It had been at +07 (not +06) for years. (Thanks to Zakhary V. Akulov.) Change data for Casey, Antarctica to agree with timeanddate.com, by adding five time zone changes since 2020. Casey is now at +08 instead of +11. Changes to past tm_isdst flags Much of Greenland, represented by America/Nuuk, changed its standard time from -03 to -02 on 2023-03-25, not on 2023-10-28. This does not affect UTC offsets, only the tm_isdst flag. (Thanks to Thomas M. Steenholdt.) New data file A new data file zonenow.tab helps configure applications that use timestamps dated from now on. This simplifies configuration, since users choose from a smaller Zone set. The file's format is experimental and subject to change. Changes to code localtime.c no longer mishandles TZif files that contain a single transition into a DST regime. Previously, it incorrectly assumed DST was in effect before the transition too. (Thanks to Alois Treindl for debugging help.) localtime.c's timeoff no longer collides with OpenBSD 7.4. The C code now uses _Generic only if __STDC_VERSION__ says the compiler is C11 or later. tzselect now optionally reads zonenow.tab, to simplify when configuring only for timestamps dated from now on. tzselect no longer creates temporary files. tzselect no longer mishandles the following: Spaces and most other special characters in BUGEMAIL, PACKAGE, TZDIR, and VERSION. TZ strings when using mawk 1.4.3, which mishandles regular expressions of the form /X{2,}/. ISO 6709 coordinates when using an awk that lacks the GNU extension of newlines in -v option-arguments. Non UTF-8 locales when using an iconv command that lacks the GNU //TRANSLIT extension. zic no longer mishandles data for Palestine after the year 2075. Previously, it incorrectly omitted post-2075 transitions that are predicted for just before and just after Ramadan. (Thanks to Ken Murchison for debugging help.) zic now works again on Linux 2.6.16 and 2.6.17 (2006). (Problem reported by Rune Torgersen.) Changes to build procedure The Makefile is now more compatible with POSIX: * It no longer defines AR, CC, CFLAGS, LDFLAGS, and SHELL. * It no longer uses its own 'cc' in place of CC. * It now uses ARFLAGS, with default specified by POSIX. * It does not use LFLAGS incompatibly with POSIX. * It uses the special .POSIX target. * It quotes special characters more carefully. * It no longer mishandles builds in an ISO 8859 locale. Due to the CC changes, TZDIR is now #defined in a file tzfile.h built by 'make', not in a $(CC) -D option. Also, TZDEFAULT is now treated like TZDIR as they have similar roles. Changes to commentary Limitations and hazards of the optional support for obsolescent C89 platforms are documented better, along with a tentative schedule for removing this support. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2023d.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2023d.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2023d.tar.lz The following convenience links are also available, although they may point to the previous release until the relevant caches are refreshed: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit cc48c2dfa2f3c21d25ab108bba978b0307ecf0e8 dated 2023-12-21 20:02:24 -0800 and tagged '2023d' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 3994a5a060a7a5fffc6585f5191cf7679f9f9be44dbcee4d67d0e42c5b6020c308cb55caf8bf8d51554697665105a174cb470c8c4fc069438350f3bac725709b tzcode2023d.tar.gz 81832b2d738c28cecbcb3906cc07568c5ae574adc9de35b25d4bf613581c92d471d67213b4261a56f0ec02efcf211b4e298b7e1dc367c972e726b0a2e9498df4 tzdata2023d.tar.gz 334f02e20d5841e60ddbdbf074f231c1564c9ac7781bad8c9813e3045d3ea0422acd1caa23a63466ca6113c396d701ccbef29669749ae844d218e4e601a9ee02 tzdb-2023d.tar.lz Here are GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmWFCxgACgkQ7ZfpDmKq fjQjkhAAuWOz1EC8Wo3ug3fU4ns0KJIk7fTV6yNKUGrjuxOmc15+Dxb8QtLKagTr 9bZBsnI1v3krgMclbuEirbkeacST0rnKbW0Dije20ZZXYUaDQ3J3nGbjOSfcnLNk dYODCQKVarkbZ70+mmm4ytvwpuQDY5W/WcP/8qXB+wTQQukAGHlglDEcdQKIwz1L aMqGzO6hd5Wv/mw0Nz16BIoEqntKLzSJE3h5h92lBhVA0em02jSrTzBZePW9k3qb VG9qjui5nrWW4nJZln15XKBz7omo7e+NEP9UFzvCWTgwKQkdGNMbTjj6cBh8wKMX SPgCBvHyGx2UzukdxXzzCEn471Ug1XNHJAAfvlEd3FkrPcUc5Hj7w0chKYibQTsm LrjUSzbIVX5EBIxEDaGWrDbahLsaw+w+Ui09nFZ/sSB1LcbCa9eGsYGHvicnBu2S RZhZWk7lL8rtQjFjOMeoLy5j3rX8zwE07BNgjmnfkxGkZJ7XdriWy937d5SLvkKN /gaaaJ/32NDzTdzkhdOLcqKi+x2wCODCNDThfM4JiOIzCFkeSlaYnqShW7CcV/9c Nh9VM9zLKkApqL9Mr/kPqT5+FmN6GunMK3y9qNwA8ROq7DpAgUWoc4ZGoeNYy5I9 XbSk2ua/gAFfJsubjZ56//eEgFsLOLcE2eyFpS0WPcIA9qVk+Jc= =ZPDg -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmWFCxkACgkQ7ZfpDmKq fjRuUxAAoioAZhZkP9DnoNvoo2YG+g4gxS4GIIw1KK6nhZqIN8F9e4wrvw6/++x/ 7FNP2+KV7ObTNlqeONv2niAL8zuFq8VhkN60D4j1qEu9H21Wxp6HFWOFEWi8l5TS l6dp4S1Rb5LmCVlbj2MbrbE6Qc+QptSdGuw12MQR34b5F8pX39vt+edMfHvA2lw0 KhMkELOaBhKCAoiVHC8onUZvCg5qEpynQ88LpKgnLWslT9fcU3m0mCuiXldSn5kp KppIlAFp6WuaKIJiuj61gjH9Py00PM7ww1+0eZbnbametmM3E2Or+YoP1pm5bIy8 77+iVCvBu+B1aW/cC1h2k3vLRUg8sFxMvGJdpow6JN1D+2e3Flk8+A8DPwRXtCRV yjjGOzIltbWwD7fisPKbvXSrVlQmMrNLMoyQcljZbYUa5nhTMoCiv+yed/DzG2ZF pwAJguKenamOiRpChFfkrVXBn/AWr4G7FVAogckFClz7qP6KSekJ0h1MzUw31c5g 8XZEwXNO2RGLbhgCw5uLg3V2KUvurSYGSBB46TnMNBLz1xRNelzkJ7XvJVIhxCEN L1t32v4jbD4YtXHqNugVId9uY3x8ed8SPdFy+8C2OqKY0TiWOTiAH2rz3vcz2L6O rsubE+4g/LUQI0fS9hTcabD9RcsP3k3/h2fZYLORM6frwuZA82U= =ylD7 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmWFCxoACgkQ7ZfpDmKq fjQiug//UW82Sq338kOG4pKEgEjoinNowfqA0cb5yZgg/wI9KKm3MSd2DqVOpySI MUwLzE2mqopxLsqrg+erdAgnaw67UqE7nkWui9zKYaON4D6XkwnFEyJTwefYzEUu WevUIMDreoK20ifcCYRNyvjFU6ik0MUVq1E5EZcli5yip4E7MRNQfiLemEe65shr ivUXndETTY06kLCf8Os7MyPxrrFc1IBB8f8fuRXcIgqqBRO+2YeViIh8iIbWIImF lO4S3Knh8Pd+6fOG5AGUcD8V7h5mZhFOVhTaKy6EWvU/98SZdGRIfszeHmgLCKmq CdKCO1K8XOITkqSWCenfTXnNELm/hsnuGPBcaRBxWXFNVLBaSaufmw0+h5IsviCo DwMqp3z7byOlNwYqeF+bYCXaoJ5ZATjCK82D5xKGLPs394/f6m46XEcQR9AU2JUR N59J0smHiH9lNzEuIcM7S8Rwwm05uVNUdHBubkz4YEWeruT5ZNlhRUnfq63Vv4ol UN5Lwqqew5V5kXmKueBHd5czN65z96EVsJTs9xMuS2OR2uekCmtqaYKhpL5DsFPH xcaAADZ1BvR2BJUmMSyXT/slyEjyK8I20irZaBGfSmAiHp9o2AW3K1pXLAXasa4E K+OAFiIqtuH7zGOIcDcj8A50KD//70nn8DPgk9S1HuQ4uTKcXBg= =IyqX -----END PGP SIGNATURE-----

1 0

Re: [tz] Antarctic research base Vostok local time
by Paul Eggert Dec. 22, 2023

Dec. 22, 2023

Unfortunately, it doesn't suffice to know just the current UTC offset. We would need to know the past UTC offsets back to at least 1970, and also to know when the base was and wasn't inhabited during that period. And we need citations to sources for this information.

3 5

Re: [tz] Definition of "timezone"
by Paul Eggert Dec. 22, 2023

Dec. 22, 2023

On 2023-12-21 07:08, ApoY2k wrote: > do you (or your > peers on the tz project) consider a "timezone" to be inherently tied to the > real-world geographical features they are used for, or is the word > "timezone" in this context more broader understood as "any 'Zone' entry in > the tzdb" - which would e.g. also denote "Etc/UTC" as a "real timezone". I'll cc this to tz(a)iana.org to see what others think. There's no formal definition. In TZDB commentary I tend to use "timezone" roughly as a synonym for "TZ setting", that is, for valid values of the TZ environment variable. In that sense there is a huge number of timezones since this includes POSIX TZ strings, and "Europe/London", "Etc/UTC" and "GMT0BST,M3.5.0/1,M10.5.0" all denote timezones. In contrast, the TZDB commentary uses "time zone" for the more common understanding in the real world, that is, the maximal-sized geographical region where clocks currently all have the same reading. In that sense there are 37 time zones right now, though the number changes depending on when you ask the question. The TZDB commentary doesn't use a name for the concept you're asking about, but I suppose "geographical timezone" would do. Admittedly the terminology is not always clear in this area. PS. I got the number "37" as follows: $ tzselect Please identify a location so that time zone rules can be set correctly. Please select a continent, ocean, "coord", "TZ", "time", or "now". 1) Africa 2) Americas 3) Antarctica 4) Arctic Ocean 5) Asia 6) Atlantic Ocean 7) Australia 8) Europe 9) Indian Ocean 10) Pacific Ocean 11) coord - I want to use geographical coordinates. 12) TZ - I want to specify the timezone using the POSIX TZ format. 13) time - I know local time already. 14) now - Like "time", but configure only for timestamps from now on. #? 14 The system says Universal Time is Thu Dec 21 20:00. Assuming that's correct, what is the local time? 1) Thu Dec 21 09:00 14) Thu Dec 21 20:00 27) Fri Dec 22 04:00 2) Thu Dec 21 10:00 15) Thu Dec 21 21:00 28) Fri Dec 22 04:45 3) Thu Dec 21 10:30 16) Thu Dec 21 22:00 29) Fri Dec 22 05:00 4) Thu Dec 21 11:00 17) Thu Dec 21 23:00 30) Fri Dec 22 05:30 5) Thu Dec 21 12:00 18) Thu Dec 21 23:30 31) Fri Dec 22 06:00 6) Thu Dec 21 13:00 19) Fri Dec 22 00:00 32) Fri Dec 22 06:30 7) Thu Dec 21 14:00 20) Fri Dec 22 00:30 33) Fri Dec 22 07:00 8) Thu Dec 21 15:00 21) Fri Dec 22 01:00 34) Fri Dec 22 08:00 9) Thu Dec 21 16:00 22) Fri Dec 22 01:30 35) Fri Dec 22 09:00 10) Thu Dec 21 16:30 23) Fri Dec 22 01:45 36) Fri Dec 22 09:45 11) Thu Dec 21 17:00 24) Fri Dec 22 02:00 37) Fri Dec 22 10:00 12) Thu Dec 21 18:00 25) Fri Dec 22 02:30 13) Thu Dec 21 19:00 26) Fri Dec 22 03:00 #?

5 8

[PROPOSED] * zonenow.tab: Explain comments column.
by Paul Eggert Dec. 21, 2023

Dec. 21, 2023

--- zonenow.tab | 3 +++ 1 file changed, 3 insertions(+) diff --git a/zonenow.tab b/zonenow.tab index aea2a90e..2dbe8f00 100644 --- a/zonenow.tab +++ b/zonenow.tab @@ -16,6 +16,9 @@ # first by standard time UTC offset; # then, if DST is used, by daylight saving UTC offset; # then by time zone abbreviation. +# 4. Every timezone has a nonempty comments column, with wording +# distinguishing the timezone only from other timezones with the +# same UTC offset at some point during the year. # # The format of this table is experimental, and may change in future versions. # -- 2.43.0

1 0

Re: [tz] [PROPOSED 00/18] tzselect improvements for configuring "from now on"
by Paul Eggert Dec. 21, 2023

Dec. 21, 2023

On 2023-12-21 03:46, Dimitry Andric wrote: > The problem is that c99 effectively runs "cc -std=iso9899:1999 -pedantic". _Generic is a C11 extension so it will then warn about that. Thanks for doing the testing. I ran into that bug with _Generic on FreeBSD 14 and installed the following workaround, which fixed things for me: https://mm.icann.org/pipermail/tz/2023-December/033364.html so if you do a "git pull" I hope this problem is fixed on FreeBSD 15-CURRENT as well. I view this as merely a bug in how clang does things. When you run 'make' in POSIX mode (by putting a ".POSIX:" line at the start of the Makefile), 'make' defaults CC to c99 (as current POSIX requires). In tzcode, even before the abovementioned patch, all uses of _Generic were protected by "#if __has_extension(c_generic_selections)" but clang complain about the uses anyway. The patch works around this clang bug by ignoring '#if __has_extension(c_generic_selections)' when it succeeds. If clang is going to diagnose any use of an extension X, then __has_extension(X) should be false. Perhaps the clang folks could implement this suggestion. > The easiest workaround is to not use c99, but "cc -std=c11", optionally with "-pedantic", that will work just fine even with ce293ccb574a77956c758a81287dbc8ef4f4eedf reverted. You can do that by editing the "#CC = ..." line in the tzcode Makefile, or by running "make CC='cc -std=c11'". We can't make these changes in tzcode's distributed Makefile, though, as that wouldn't be portable. > In addition, -pedantic is known to complain about GNU extensions such as __builtin_offsetof. There is not much you can do about that, since we make extensive use of such extensions in the FreeBSD system headers. Yes, your email contained the following messages indicating this problem: > zic.c:2395:11: warning: defining a type within '__builtin_offsetof' is a Clang extension [-Wgnu-offsetof-extensions] > 2395 | alignof(zic_t))); > | ^~~~~~~~~~~~~~ > zic.c:74:33: note: expanded from macro 'alignof' > 74 | # define alignof(type) offsetof(struct { char a; type b; }, b) > | ^~~~~~ > /usr/include/stddef.h:71:42: note: expanded from macro 'offsetof' > 71 | #define offsetof(type, field) __offsetof(type, field) > | ^~~~ > /usr/include/sys/cdefs.h:424:53: note: expanded from macro '__offsetof' > 424 | #define __offsetof(type, field) __builtin_offsetof(type, field) > | ^~~~ I don't see this message in FreeBSD 14, so this is a regression in FreeBSD 15. And it appears to be another bug in FreeBSD and/or clang. First, any code using __builtin_offsetof is using a GNU extension, so why warn about __builtin_offsetof with a particular argument that happens to be a new type? And second, "__builtin_offsetof(struct { char a; type b; }, b)" doesn't define any type that can be used anywhere else, so why warn about the type? And third, there's nothing in C99 that prohibits the use of "offsetof(struct { char a; type b; }, b)" and it works on every C99 platform, so why warn about it? I reproduced the problem on Fedora 39 with "make CC='clang -std=iso9899:1999 -pedantic'", and attempted to pacify clang with the attached patch, but that merely changed the diagnostics to be something like this: zic.c:2408:11: warning: '_Alignof' is a C11 extension [-Wc11-extensions] 2408 | alignof(zic_t))); | ^ /usr/bin/../lib/clang/17/include/stdalign.h:19:17: note: expanded from macro 'alignof' 19 | #define alignof _Alignof | ^ 1 warning generated. Since this bug is only a warning, perhaps we should give up trying to work around it. I hope the clang folks fix the bug eventually.

1 0

Re: [tz] Antarctic research base Vostok local time
by Paul Eggert Dec. 21, 2023

Dec. 21, 2023

On 2023-12-18 19:14, АПС АКУЛОВ wrote: > >Do you have a public announcement on the web, or some other source, > that we can cite? > Well AARI weekly publishes Antarctic events summaries here: > https://www.aari.ru/press-center/news/rae . > > But I am not sure if my case will be mentioned there. This web page still says that Vostok time is UTC+07: https://www.aari.ru/ekspeditsii/rossiyskaya-antarkticheskaya-ekspeditsiya-(… Could you please fix that web page? That would help confirm the change, so that when people ask us for our source, we can direct them to aari.ru. > >Does "00:00" mean 00:00 local time, or 00:00 UTC? > > My bad, sorry, I missed this point. > > Local time, of source. OK. Did clocks jump back from 00:00 today to 22:00 the previous day, or from 02:00 to 00:00 today? Also, could you please briefly say why Vostok changed from UTC+07 to UTC+05? I would like to document this in commentary. > >Has local time at Vostok been UTC+6 ever since 1957, or has it changed > before? > > No. At least since my antarctic career start, 10 years ago, Vostok base > has UTC+7. Ouch. TZDB has been wrong for Vostok for at least 10 years. I will try to correct this. (I hope you have not been at Vostok for 10 years! I'd rather live in Siberia, or even in Nebraska. I can joke about this, as I was born in Nebraska....) Attached is a draft patch to TZDB to implement these changes. Please let us know if you see problems with it. I have not installed this patch into the TZDB development repository as it is still preliminary.

6 12

[PROPOSED] * zonenow.tab: Fix Troll DST offset in comment.
by Paul Eggert Dec. 21, 2023

Dec. 21, 2023

--- zonenow.tab | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zonenow.tab b/zonenow.tab index c03e0bba..aea2a90e 100644 --- a/zonenow.tab +++ b/zonenow.tab @@ -132,7 +132,7 @@ XX +513030-0000731 Europe/London United Kingdom ("GMT/BST") # +00/+01 - WET/WEST (EU DST) XX +3843-00908 Europe/Lisbon western Europe ("WET/WEST") # -# +00/+01 - Troll DST +# +00/+02 - Troll DST XX -720041+0023206 Antarctica/Troll Troll Station in Antarctica # # +01 - CET -- 2.43.0

1 0

[PROPOSED 00/18] tzselect improvements for configuring "from now on"
by Paul Eggert Dec. 21, 2023

Dec. 21, 2023

For some time I've been meaning to extend tzselect so that users who care only about timestamps from now on can have a smaller set of timezones to choose from, thus simplifying configuration. This patchset does this via a new file zonenow.tab, with contents like zone1970.tab except that zonenow.tab partitions based on timestamps from now on, instead of from 1970 on. The new file's format is still experimental and feedback is welcome. These patches mostly just refactor tzselect, to simplify support for the new feature. The last patch adds the new feature. Paul Eggert (18): More-systematic punctuation in *.tab comments Improve Canadian comments in zone*.tab Open /dev/null less often in tzselect * Makefile: Say that ‘make’ should conform to POSIX. Improve tzselect diagnostics after rejection Don’t set TZ in tzselect Do not use empty RE in tzselect Port to POSIX awk, which prohibits -v newlines tzselect: work around mawk bug with {2,} * tzselect: Improve leading comments. tzselect: clarify translit need tzselect: port to POSIX iconv * NEWS: Improve formatting of tzselect news. tzselect: do not create temporary files * tzselect: Indent more consistently. * tzselect.ksh: Consistently omit ‘;;’ before ‘esac’. * tzselect.ksh: Indent more consistently. New tzselection option ‘now’ Makefile | 34 +- NEWS | 28 +- checknow.awk | 53 +++ checktab.awk | 7 +- tzselect.ksh | 977 ++++++++++++++++++++++++++++----------------------- zone.tab | 24 +- zone1970.tab | 24 +- zonenow.tab | 298 ++++++++++++++++ 8 files changed, 978 insertions(+), 467 deletions(-) create mode 100644 checknow.awk create mode 100644 zonenow.tab -- 2.40.1

4 25

[PROPOSED 0/9] Fixes for Casey and for portability
by Paul Eggert Dec. 21, 2023

Dec. 21, 2023

Most of these fixes are so that ‘make check’ passes, or improve commentary. The more noticeable changes are to the Antarctica/Casey data (where there’s a good chance we’re still wrong but at least we’re more in sync with timeanddate.com) along with code portability fixes for FreeBSD and OpenBSD. Paul Eggert (9): Distribute new file checknow.awk too Fix ‘make check_character_set’ false positive Update tzselect comment for Solaris 10 EOL * checknow.awk: Fix typo in empty-input diagnostic. Port ‘make check_now’ to macOS Pacify FreeBSD 14 c99 Sync Casey data from timeanddate.com Port localtime.c timeoff to OpenBSD 7.4 * NEWS: Mention a few more post-2023c changes. Makefile | 27 ++++++++++++++++----------- NEWS | 13 +++++++++++++ antarctica | 12 +++++++++++- checknow.awk | 3 ++- localtime.c | 3 +++ private.h | 4 +--- tzselect.ksh | 2 +- 7 files changed, 47 insertions(+), 17 deletions(-) -- 2.43.0

1 9

Re: [tz] leap_second.list not updated after latest IERS Bulletin C
by Paul Eggert Dec. 19, 2023

Dec. 19, 2023

On 12/7/23 13:21, Geert Hendrickx wrote: > NTPsec logs the following at startup: > > CLOCK: leapsecond file ('/etc/ntp/leap-seconds.list'): good hash signature > > CLOCK: leapsecond file ('/etc/ntp/leap-seconds.list'): loaded, expire=2024-06-28T00:00Z last=2017-01-01T00:00Z ofs=37 > > > So I *guess* (without having looked at the code) that it actually cares > about the expiration date as well. I think you're right NTPsec does care, though I vaguely recall that if the file has expired the only issue is an unwanted log message. If people are running NTPsec and configuring it to use TZDB's leap-seconds.list, that unwanted log message could be an issue. I just now checked the NTPsec source code, though, and by default it uses this URL: https://www.ietf.org/timezones/data/leap-seconds.list which hasn't worked in a while; the contents are simply "ietf.org is no longer serving this file." So it may be that we don't need to issue a new TZDB release merely because 2023c's leap-seconds.list will be out-of-date soon. > (but we periodically download it from IERS, not from TZ) In that case your setup is OK as-is, though we may still need to hear from other people to see whether they're relying on the TZDB copy of leap-seconds.list. TZDB uses the NIST version of leap-seconds.list rather than the IERS version, as the NIST version is clearly public domain and so this way we don't have to worry about copyright issues. However, the IERS version should work fine with either NTPsec or with other downstream uses, such as TZDB itself (that is, if you're not worried about copyright).

9 23

Antarctic research base Vostok local time
by АПС АКУЛОВ Dec. 19, 2023

Dec. 19, 2023

Pse be informed that from December, 18, 2023 00:00 by my decision the local time of the Antarctic research base Vostok will correspond to UTC+5. Sincerely, Chief of Antarctic research base Vostok, Zakhary V. Akulov -- УВАЖЕНИЕМ= АПС АКУЛОВ= 69 РАЭ СТ ВОСТОК-

4 5

[BUG] Expression is always zero
by RekGRpth Dec. 14, 2023

Dec. 14, 2023

The value of expression 'thistimecnt >> 31 >> 31 >> 2' (in zic.c) is zero regardless of the value of the left operand 'thistimecnt', because it is shifted by 64 (in total) bits, which is greater or equal to its size of 64 bits. Maybe this was what was meant? thistimecnt >> 31 >> 2

2 1

Tab/Space Formatting Inconsistency - Asia Ver 2023c
by Gary Cho Dec. 13, 2023

Dec. 13, 2023

Hello, While writing software to parse through the database, I found the following inconsistencies in the "asia" file 1) Line 3463 to 3569 - Rule should be followed by a tab instead of a space 2) Line 3587 ,3589,3591,3593 - STDOFF should be followed by a tab instead of space 3) Line 3096 - STDOFF should be followed by a tab instead of space Gary Cho

7 7

leap_second.list not updated after latest IERS Bulletin C
by Maximilian Linhoff Dec. 11, 2023

Dec. 11, 2023

Dear IANA Timezone People, The latest leap_seconds.lst file you provide here: https://data.iana.org/time-zones/tzdb/leap-seconds.list and the other related files were last updated 2023-03-28. The leap second table has an expiry date of 2023-12-28, which is rapidly approaching. There is IERS Bulletin C from 2023-07-04 announcing no new leap second on 2023-12-31, so the expiry date of the list can be updated to 2023-06-28. Kind regards Maximilian Linhoff -- Dr. Maximilian Linhoff PostDoc Astroteilchenphysik Technische Universität Dortmund Fakultät Physik / Astroteilchenphysik Otto-Hahn-Str. 4a 44227 Dortmund Tel.: +49 231 755 8895 maximilian.linhoff(a)tu-dortmund.de https://app.tu-dortmund.de

2 2

Re: [tz] leap_second.list not updated after latest IERS Bulletin C
by Hal Murray Dec. 8, 2023

Dec. 8, 2023

Paul Eggert said: > Is there some reason we need a new TZDB release because of this? Do you use > software that requires that this file come from a TZDB release, rather than > from other sources such as the one mentioned above? Yes, NTP can use the leap file from other sources. The idea of distributing it with TZDB is that it removes an operational step from running NTP with (hopefully) minimal work on the TZ team and OS distros since they are already distributing TZ info. Debian's ntpsec.conf now contains: leapfile /usr/share/zoneinfo/leap-seconds.list > I recall that traditionally ntpd needed leap-seconds.list and looked at the > expiration but am not up to date with what its successor NTPsec is doing. NTPsec uses the expiration date. Long version: GPS satellites distribute leap second info. Some receivers pass that on to the clients. So does NIST's ACTS phone/modem time service. WWVB in US, JJY in Japan, MSF in UK, and DCF77 in Germany also provide leap second info. I'm not sure how many receivers make that available. NTP can get leap info from 3 sources: file, radio, and network. If it has a valid file, it believes that. If it doesn't have a file, next in line is a local refclock. With no file and no refclocks, it gets leap info from network time servers. So a valid file when there is no leap pending will keep ntpd from believing buggy or malicious NTP servers on the net. I think there was an event where a bunch of servers didn't stop advertising a leap. It was many years ago. I've forgotten the details. I think the code was changed from believing one server to requiring a majority. There is a subtle difference between no-known-leap and known-no-leap. The NTP packet format doesn't have a way to indicate known-no-leap and that gap probably percolates through the code. It may not actually work as I described above but that's the way it should work. -- These are my opinions. I hate spam.

1 0