- tz - lists.iana.org

[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

If leap seconds go away, should TZif leap-second tables expire?
by Paul Eggert Nov. 29, 2023

Nov. 29, 2023

I have a question about leap-second table expiration in TZif files. Please bear with a longish explanation first; the actual question is at the end of this message. Since release 2020a, TZDB's zic command has supported "Expires" lines in the leapseconds file, and has propagated that info to TZif files using an extension to Internet RFC 8536. This extension is a bit of a hack: if a TZif file's last leap-second record has the same correction as the penultimate record, then the last record is the leap second expiry. For example, if the file 'leap-seconds.list' contains the line: #@ 3928521600 which stands for 28 June 2024; and if you run the command 'make EXPIRES_LINE=1 leapseconds', the file 'leapseconds' will contain: Expires 2024 Jun 28 00:00:00 and if you then run 'make install', the resulting TZif files with leap seconds will contain two leap transitions with correction 27, one transition for 1483228826 (representing 2016-12-31 23:59:60 UTC, the most recent leap second), and one transition for 1719532827 (representing 2017-06-28 00:00:00 UTC, the leap second table expiration). This Expires-line feature was introduced to TZDB in release 2020a, replacing an older hack using an "#expires" comment. However, in the interest of stability the feature has been disabled by default and you must use a non-default setting like "make EXPIRES_LINE=1" to enable it. Our current draft -09 revision to Internet RFC 8536 documents this new feature for the planned version 4 of the TZif file. See <https://datatracker.ietf.org/doc/draft-murchison-rfc8536bis/09/> section 3.2 item "corr(ection)", which says: "... in version 4 files with two or more leap-second records, the correction value of the last two records MAY be the same, with the occurrence of last record indicating the expiration time of the leap-second table." "The leap-second table expiration time is the time at which the table no longer records the presence or absence of future leap- second corrections, and post-expiration timestamps can not be accurately calculated. For example, a leap-second table published in January, which predicts the presence or absence of a leap second at June's end, might expire in mid-December because it is not known whether a leap second will occur at December's end. To complicate matters, a year ago the General Conference on Weights and Measures adopted a resolution calling for leap seconds to be phased out by 2035 <https://www.bipm.org/en/cgpm-2022/resolution-4>. If this is indeed done as late as possible there's a chance we could have our first-ever negative leap second before 2035 <https://insidegnss.com/will-we-have-a-negative-leap-second/> which could cause software havoc, and it's not clear whether the authorities would go through with this. One more thing: the World Radio Conference is currently meeting in Dubai and this meeting may take further action regarding leap seconds. Draft -09 currently has the following text about the possible impending demise of leap seconds: "If leap seconds become permanently discontinued, as requested by the General Conference on Weights and Measures [CGPM-2022-R4], leap-second tables published after the discontinuation time SHOULD NOT expire, since they will not be updated in the foreseeable future." With all the above in mind, here is my question. Should TZif leap-second tables have no expiration date if leap seconds are discontinued, as draft -09 suggests? Or should they have an expiration date of (say) January 2100, which is likely a lower bound on the date that the leap-second regime would be replaced by some other regime, such as leap minutes? Or should we do something else about TZif leap-second expiry after leap seconds are discontinued?

6 9

Re: [tz] If leap seconds go away, should TZif leap-second tables expire?
by Hal Murray Nov. 29, 2023

Nov. 29, 2023

Paul Eggert said: > Should TZif leap-second tables have no expiration date if leap seconds are > discontinued, as draft -09 suggests? Or should they have an expiration date > of (say) January 2100, which is likely a lower bound on the date that the > leap-second regime would be replaced by some other regime, such as leap > minutes? Or should we do something else about TZif leap-second expiry after > leap seconds are discontinued? I suggest waiting. Everybody else is going to have the same problem. As part of working out the no-leap details, somebody will have to pick a value so they can say something like "we won't have any leaps for the next N years". Then you can plug that number in. -- These are my opinions. I hate spam.

1 0

Re: [tz] localtime crash and fix
by Alois Treindl Nov. 29, 2023

Nov. 29, 2023

Thanks for fixing. I still find the code unnecessarily obscure due to the use of two unions stacked inside each other. > /* Input buffer for data read from a compiled tz file. */ > union input_buffer { > /* The first part of the buffer, interpreted as a header. */ > struct tzhead tzhead; > > /* The entire buffer. */ > char buf[2 * sizeof(struct tzhead) + 2 * sizeof(struct state) > + 4 * TZ_MAX_TIMES]; > }; > > /* TZDIR with a trailing '/' rather than a trailing '\0'. */ > static char const tzdirslash[sizeof TZDIR] = TZDIR "/"; > > /* Local storage needed for 'tzloadbody'. */ > union local_storage { > /* The results of analyzing the file's contents after it is opened. */ > struct file_analysis { > /* The input buffer. */ > union input_buffer u; > > /* A temporary state used for parsing a TZ string in the file. */ > struct state st; > } u; > > /* The file name to be opened. */ > char fullname[max(sizeof(struct file_analysis), sizeof tzdirslash + 1024)]; > }; The size of local_starage is in the range of 80 kb, not exactly something for a "small stack". The element buf is rather large. I think you save only 1kb extra spece for fullname, and some 30 bytes for tzhead. I do not think that these very minor saving justify the obscurity introduced in the code. It makes it hard to read and hard to debug. Please consider that others want to understand tzcode also. > Am 24.11.2023 um 23:14 schrieb Paul Eggert <eggert(a)cs.ucla.edu>: > > On 2023-11-24 08:22, Alois Treindl via tz wrote: >> The use of union to save memory is dangerous, in my opinion. There is no need in today's machines to save a few kilobytes of RAM for a process. >> Not even in embedded software for watches. > > When the memory is on the stack it still makes sense in some cases to save even a few kilobytes of RAM, as highly-threaded apps often have surprisingly small stacks. And anyway, the union has nothing to do with this particular bug.

2 1

[PROPOSED] Fix zic bug with -r @X where X is deduced from TZ
by Paul Eggert Nov. 27, 2023

Nov. 27, 2023

Problem reported by Ken Murchison for ‘zic -b slim -r @2145916800 asia’, which generated an Asia/Jerusalem TZif file with a single transition from -00 to IDT at 2145916800 (2038-01-01 00:00:00 UTC). The transition should be to IST. * NEWS: Mention this. * zic.c (main): Don’t let redundant_time be lower than lo_time. (outzone): Fix code for omitting trailing transitions when -R is specified, which was inadvertently messed up by the 2023-10-15 fix for Palestine after 2075. --- NEWS | 3 ++- zic.c | 15 +++++++++++---- 2 files changed, 13 insertions(+), 5 deletions(-) diff --git a/NEWS b/NEWS index 0d7fde80..c07cc7ad 100644 --- a/NEWS +++ b/NEWS @@ -37,7 +37,8 @@ Unreleased, experimental changes 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. + 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.) diff --git a/zic.c b/zic.c index e10cb21b..b260851f 100644 --- a/zic.c +++ b/zic.c @@ -897,7 +897,8 @@ static zic_t const max_time = MAXVAL(zic_t, TIME_T_BITS_IN_FILE); static zic_t lo_time = MINVAL(zic_t, TIME_T_BITS_IN_FILE); static zic_t hi_time = MAXVAL(zic_t, TIME_T_BITS_IN_FILE); -/* The time specified by the -R option, defaulting to MIN_TIME. */ +/* The time specified by the -R option, defaulting to MIN_TIME; + or lo_time, whichever is greater. */ static zic_t redundant_time = MINVAL(zic_t, TIME_T_BITS_IN_FILE); /* The time specified by an Expires line, or negative if no such line. */ @@ -1109,6 +1110,8 @@ main(int argc, char **argv) fprintf(stderr, _("%s: -R time exceeds -r cutoff\n"), progname); return EXIT_FAILURE; } + if (redundant_time < lo_time) + redundant_time = lo_time; if (bloat == 0) { static char const bloat_default[] = ZIC_BLOAT_DEFAULT; if (strcmp(bloat_default, "slim") == 0) @@ -3442,6 +3445,9 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) if (defaulttype < 0) defaulttype = 0; if (!do_extend && !want_bloat()) { + /* Keep trailing transitions that are no greater than this. */ + zic_t keep_at_max; + /* The earliest transition into a time governed by the TZ string. */ zic_t TZstarttime = ZIC_MAX; for (i = 0; i < timecnt; i++) { @@ -3452,10 +3458,11 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) if (TZstarttime == ZIC_MAX) TZstarttime = nonTZlimtime; - /* Omit trailing transitions deducible from the TZ string. */ + /* Omit trailing transitions deducible from the TZ string, + and not needed for -r or -R. */ + keep_at_max = max(TZstarttime, redundant_time); for (i = j = 0; i < timecnt; i++) - if (redundant_time <= attypes[i].at - && attypes[i].at <= TZstarttime) { + if (attypes[i].at <= keep_at_max) { attypes[j].at = attypes[i].at; attypes[j].dontmerge = (attypes[i].at == TZstarttime && (nonTZlimtype != attypes[i].type -- 2.40.1

1 0

[PROPOSED 1/4] Fix bug with ‘make typecheck; make clean’
by Paul Eggert Nov. 25, 2023

Nov. 25, 2023

* Makefile (clean_misc): Also remove typecheck_*.dir. --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 8df3b621..edbc4d16 100644 --- a/Makefile +++ b/Makefile @@ -944,7 +944,7 @@ check_zishrink_posix check_zishrink_right: \ touch $@ clean_misc: - rm -fr check_*.dir + rm -fr check_*.dir typecheck_*.dir rm -f *.o *.out $(TIME_T_ALTERNATIVES) \ check_* core typecheck_* \ date tzselect version.h zdump zic libtz.a -- 2.40.1

1 3

Re: [tz] localtime crash and fix
by Alois Treindl Nov. 24, 2023

Nov. 24, 2023

That is effectively the same. But I would rather if Paul Eggert fixed the code. When I diff localtime.c from 2023c release with the current github version, there are changes which are obscure to me. The use of union to save memory is dangerous, in my opinion. There is no need in today's machines to save a few kilobytes of RAM for a process. Not even in embedded software for watches. It makes the code obscure. I have the gut feeling that the bug is in the line sp->goahead = ts->goahead; where ts has inherited old data from a previous call. On 24.11.23 16:54, Carlo wrote: > Dear Alois > > > Have you tried using this, letting the compiler perform the memset: > > #else > union local_storage ls = {0}; > return tzloadbody(name, sp, doextend, &ls); > #endif > > On Thu, Nov 23, 2023 at 7:32 PM Alois Treindl via tz <tz(a)iana.org> wrote: > > I have observed occasional crashes in localtime.c in the current > github version. > > In one of my applications, localtime() is called multiple times > for several zones. > > The condition when the segmentation fault appears are herd to > reproduce or demonstrate. > > This patch in function tzload() however solves the issue: > > --- localtime.c 2023-11-16 20:18:01.904577574 +0100 > +++ a/localtime.c 2023-11-23 19:22:21.062249899 +0100 > @@ -769,6 +769,7 @@ > } > #else > union local_storage ls; > + memset(&ls, 0, sizeof(ls)); > return tzloadbody(name, sp, doextend, &ls); > #endif > } >

2 1