- tz - lists.iana.org

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

localtime crash and fix
by Alois Treindl Nov. 24, 2023

Nov. 24, 2023

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 }

1 3

Did Greenland abolish daylight saving from 2024 on?
by Paul Eggert Nov. 20, 2023

Nov. 20, 2023

This week several English-language news sources reported that Greenland has moved its clocks forward for the last time. These reports disagree with current TZDB[1], which follows Thomas M. Steenholdt's December email[2] saying that although in November Greenlanders voted to not fall back this fall, they also voted to continue to observe daylight saving time (DST) next year, effectively moving their time zone one hour east instead of abolishing DST. There's no disagreement about timekeeping this year. The first point of disagreement is March 30, 2024 at 23:00, when TZDB says Nuuk, Greenland will spring forward to 24:00, whereas the recent news reports say clocks will neither spring forward nor fall back during 2024. So who's right: Steenholdt in December, or these several recent news reports? Currently TZDB goes with Steenholdt. After all, he cited the relevant Greenland legislation and his email address ends in ".gl". I suppose another possibility, though, is that Greenland's government has changed its mind since November. However, if so I'd like to see citations to the newer legislation. The earliest recent news story I found on this topic was a week ago by Lebawit Lily Girma[3], senior travel news reporter for Bloomberg Pursuits. I'm taking the liberty of bcc'ing Girma to see if she can help get to the bottom of the situation. [1]: https://iana.org/tz [2]: https://mm.icann.org/pipermail/tz/2022-December/032402.html [3]: Girma LL. Greenland Solves the Daylight Saving Time Debate. Bloomberg. 2023-03-24. https://www.bloomberg.com/news/articles/2023-03-24/greenland-keeps-daylight… Here are some of the other news reports I found. Greenland to stay in daylight saving time forever. AP. 2023-03-27. https://apnews.com/article/greenland-daylight-saving-summertime-utc-gmt-3b5… Martin M. Greenland is keeping daylight saving time permanently. NPR. 2023-03-28. https://www.wunc.org/2023-03-28/greenland-is-keeping-daylight-saving-time-p… Selcho M. Here’s why Greenland is permanently keeping daylight saving time. Deseret News. 2023-03-28. https://www.deseret.com/u-s-world/2023/3/28/23660379/why-greenland-keeping-… Jerusalem Post staff. Greenland changed their clocks to daylight savings for the last time. Jerusalem Post. 2023-03-29. https://www.jpost.com/international/article-735751 Carpineti A. Greenland Has Changed Its Clocks For The Last Time, Embracing Daylight Savings Forever. IFLScience. 2023-03-29. https://www.iflscience.com/greenland-has-changed-its-clocks-for-the-last-ti…

16 48

make error
by Alois Treindl Nov. 20, 2023

Nov. 20, 2023

I just made a new clone of tz. I work normally on RHEL 7 (redhat enterprise Linux) with gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) When I say make or make all, I get something I never observed before: cc -DTZDIR='"/usr/share/zoneinfo"' -c -o zic.o zic.c In file included from zic.c:16:0: private.h:791:60: error: conflicting types for ‘restrict’ struct tm *localtime_rz(timezone_t restrict, time_t const *restrict, ^ private.h:791:36: note: previous definition of ‘restrict’ was here struct tm *localtime_rz(timezone_t restrict, time_t const *restrict, ^ private.h:792:15: error: conflicting types for ‘restrict’ struct tm *restrict); ^ private.h:791:60: note: previous definition of ‘restrict’ was here struct tm *localtime_rz(timezone_t restrict, time_t const *restrict, ^ private.h:793:49: error: conflicting types for ‘restrict’ time_t mktime_z(timezone_t restrict, struct tm *restrict); ^ private.h:793:28: note: previous definition of ‘restrict’ was here time_t mktime_z(timezone_t restrict, struct tm *restrict); This does not happen when I compile on RHEL 9 gcc version 11.4.1 20230605 (Red Hat 11.4.1-2) (GCC) Can anyone point me to a fix?

7 17

[PROPOSED 1/5] * tz-link.html: Minor tweaks to citations.
by Paul Eggert Nov. 19, 2023

Nov. 19, 2023

--- tz-link.html | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tz-link.html b/tz-link.html index a29231d5..84bea935 100644 --- a/tz-link.html +++ b/tz-link.html @@ -994,9 +994,9 @@ are larger for countries farther away from the equator, while subtropical regions consume more electricity because of <abbr>DST</abbr>."</li> <li>Malow BA. It is time to abolish the clock change and adopt permanent standard time in the United States: a Sleep Research Society position statement. -Sleep. 2022;45(12):zsac236. +Sleep. 2022;45(12):zsac236. doi:<a href="https://doi.org/10.1093/sleep/zsac236">10.1093/sleep/zsac236</a>. -After reviewing of the scientific literature, the Sleep Research Society +After reviewing the scientific literature, the Sleep Research Society advocates permanent standard time due to its health benefits. <li>Rishi MA, Cheng JY, Strang AR et al. <a href="https://jcsm.aasm.org/doi/10.5664/jcsm.10898">Permanent standard time @@ -1004,15 +1004,15 @@ is the optimal choice for health and safety: an American Academy of Sleep Medicine position statement</a>. J Clin Sleep Med. 2023-10-31. doi:<a href="https://doi.org/10.5664/jcsm.10898">10.5664/jcsm.10898</a>. -This argues for permanent standard time due to health and safety risks +The AASM argues for permanent standard time due to health and safety risks and economic costs of both <abbr>DST</abbr> transitions and permanent <abbr>DST</abbr>.</li> <li>Roenneberg T, Wirz-Justice A, Skene DJ et al. <a href="https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7205184/">Why should we abolish Daylight Saving Time?</a> -J Biol Rhythms. 2019;34(3):227–230. +J Biol Rhythms. 2019;34(3):227–230. doi:<a href="https://doi.org/10.1177/0748730419854197">10.1177/0748730419854197</a>. -This position paper of the Society for Research on Biological Rhythms +The Society for Research on Biological Rhythms opposes DST changes and permanent DST, and advocates that governments adopt "permanent Standard Time for the health and safety of their citizens".</li> </ul> -- 2.40.1

1 4

building on Windows
by David Stiff Nov. 15, 2023

Nov. 15, 2023

Hello, would you be able to advise on building tz on Windows? Is there a Windows makefile? Thanks! Dave Stiff Wolfram Research

2 3

Time zone of Iceland in Africa?
by tz＠schwilli.at Nov. 14, 2023

Nov. 14, 2023

Hi, I would expect to find the time zone of Iceland/Reykjavik in Europe or Atlantic Ocean but it is in Africa: ------------------------ # tzselect Please identify a location so that time zone rules can be set correctly. Please select a continent, ocean, "coord", or "TZ". 1) Africa 2) Americas 3) Antarctica 4) Asia 5) Atlantic Ocean 6) Australia 7) Europe 8) Indian Ocean 9) Pacific Ocean 10) coord - I want to use geographical coordinates. 11) TZ - I want to specify the timezone using the Posix TZ format. #? 1 Please select a country whose clocks agree with yours. 1) Algeria 20) Gabon 39) Nigeria 2) Angola 21) Gambia 40) Rwanda 3) Benin 22) Ghana 41) Sao Tome & Principe 4) Botswana 23) Guinea 42) Senegal 5) Burkina Faso 24) Guinea-Bissau 43) Sierra Leone 6) Burundi 25) Iceland 44) Somalia 7) Cameroon 26) Kenya 45) South Africa 8) Central African Rep. 27) Lesotho 46) South Sudan 9) Chad 28) Liberia 47) Spain 10) Comoros 29) Libya 48) St Helena 11) Congo (Dem. Rep.) 30) Madagascar 49) Sudan 12) Congo (Rep.) 31) Malawi 50) Tanzania 13) Côte d'Ivoire 32) Mali 51) Togo 14) Djibouti 33) Mauritania 52) Tunisia 15) Egypt 34) Mayotte 53) Uganda 16) Equatorial Guinea 35) Morocco 54) Western Sahara 17) Eritrea 36) Mozambique 55) Zambia 18) Eswatini (Swaziland) 37) Namibia 56) Zimbabwe 19) Ethiopia 38) Niger #? 25 The following information has been given: Iceland Therefore TZ='Africa/Abidjan' will be used. Selected time is now: Fri Sep 15 05:44:06 GMT 2023. Universal Time is now: Fri Sep 15 05:44:06 UTC 2023. Is the above information OK? 1) Yes 2) No #? 1 You can make this change permanent for yourself by appending the line TZ='Africa/Abidjan'; export TZ to the file '.profile' in your home directory; then log out and log in again. Here is that TZ value again, this time on standard output so that you can use the /usr/bin/tzselect command in shell scripts: Africa/Abidjan ------------------------ Why is it mapped to 'Africa/Abidjan'? # tzselect --version tzselect (GNU libc) 2.35 release of tz code and data: 2023c Thx, Reinhard

8 14