December 2023 - tz - lists.iana.org

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