- tz - lists.iana.org

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