- tz - lists.iana.org

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

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

Request for Standardization of Kyiv Time Zone Naming
by Dmytro Shynkarenko Nov. 11, 2023

Nov. 11, 2023

Dear IANA Team, I'm reaching out on behalf of our team at Tutorpeers (Tutorpeers.com) I'm reaching out to address a significant concern related to the naming of Ukraine's capital in time zone databases. At present, there are two spellings in use: "Kiev" and "Kyiv." The latter, "Kyiv," is the correct Ukrainian spelling and pronunciation, which honors the country's sovereignty and the preferences of its people. The use of "Kiev," which is derived from the Russian language, has become increasingly problematic, especially considering Russia's ongoing aggression against Ukraine. This issue hits close to home for me, not only because of my Ukrainian roots but also due to the feedback we've received from our Ukrainian user base. Numerous customers have reached out to us, expressing discomfort and disapproval of the "Kiev" spelling, given the current circumstances. Our platform has taken a clear stance on this issue, and we urge IANA to consider the implications of language and to update its time zone databases accordingly. By standardizing the "Kyiv" spelling, we can collectively show support for the Ukrainian community and respect their cultural and national identity. After speaking to your colleague Candice Montoya I was pleased to learn that the spelling change to "Europe/Kyiv" has already been implemented in the Time Zone Database as of August 2022. This update is much appreciated and reflects a positive and respectful acknowledgment of the correct naming convention. However, I've noticed that the previous spelling, "Kiev" still appears in some instances. Please confirm if this is intended for backward compatibility with existing systems. And if so, is there a planned timeline for its eventual deprecation in favor of the updated "Kyiv" spelling? Understanding the strategy for phasing out the old spelling would be incredibly helpful for our team and user community as we navigate these changes and ensure we provide the most current and accurate information. Thank you once again for your attention to this matter. Regards, Dmytro Project Coordinator at Tutorpeers

4 3

Error for Chile on September 2023
by Jacqueline Seron Nov. 7, 2023

Nov. 7, 2023

Hello On September 2023, Chile changed the date for DST from September 3rd to September 11th. I do not see this change in the database. See the government webpage that indicated this change https://horaoficial.cl/CambioHusoHorario.php Thank you -- Jacqueline Seron N. NOIRLab - AURA

8 16

[PROPOSED] Update AASM citation to 2023
by Paul Eggert Nov. 1, 2023

Nov. 1, 2023

* tz-link.html (Costs and benefits of time shifts): Link to 2023 edition of the American Academy of Sleep Medicine position statement. --- tz-link.html | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/tz-link.html b/tz-link.html index 19740b11..a29231d5 100644 --- a/tz-link.html +++ b/tz-link.html @@ -998,13 +998,15 @@ standard time in the United States: a Sleep Research Society position statement. 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 advocates permanent standard time due to its health benefits. -<li>Rishi MA, Ahmed O, Barrantes Perez JH et al. -<a href="https://jcsm.aasm.org/doi/10.5664/jcsm.8780">Daylight saving time: +<li>Rishi MA, Cheng JY, Strang AR et al. +<a href="https://jcsm.aasm.org/doi/10.5664/jcsm.10898">Permanent standard time +is the optimal choice for health and safety: an American Academy of Sleep Medicine position statement</a>. -J Clin Sleep Med. 2020;16(10):1781–1784. -doi:<a href="https://doi.org/10.5664/jcsm.8780">10.5664/jcsm.8780</a>. -This argues for permanent standard time due to health risks of both -<abbr>DST</abbr> transitions and permanent <abbr>DST</abbr>.</li> +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 +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> -- 2.41.0

1 0

[PROPOSED] Ittoqqortoormiit (America/Scoresbysund) zone change
by Paul Eggert Oct. 29, 2023

Oct. 29, 2023

* NEWS: Mention this. * europe (America/Scoresbysund): Switch to -02/-01 on 2024-03-31. --- NEWS | 8 ++++++++ europe | 14 +++++++++++++- 2 files changed, 21 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 9a085948..e5ead4cf 100644 --- a/NEWS +++ b/NEWS @@ -3,10 +3,18 @@ News for the tz database Unreleased, experimental changes Briefly: + Ittoqqortoormiit, Greenland changes time zones on 2024-03-31. Code and data fixes for Palestine timestamps starting in 2072. 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. diff --git a/europe b/europe index 012d1498..6e59f62d 100644 --- a/europe +++ b/europe @@ -1130,6 +1130,17 @@ Zone Atlantic/Faroe -0:27:04 - LMT 1908 Jan 11 # Tórshavn # However, Greenland will change to Daylight Saving Time again in 2024 # and onwards. +# From an contributor who wishes to remain anonymous for now (2023-10-29): +# https://www.dr.dk/nyheder/seneste/i-nat-skal-uret-stilles-en-time-tilbage-m… +# with a link to that page: +# https://naalakkersuisut.gl/Nyheder/2023/10/2710_sommertid +# ... Ittoqqortoormiit joins the time of Nuuk at March 2024. +# What would mean that America/Scoresbysund would either be in -01 year round +# or in -02/-01 like America/Nuuk, but no longer in -01/+00. +# +# From Paul Eggert (2023-10-29): +# For now, assume it will be like America/Nuuk. + # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule Thule 1991 1992 - Mar lastSun 2:00 1:00 D Rule Thule 1991 1992 - Sep lastSun 2:00 0 S @@ -1149,7 +1160,8 @@ Zone America/Danmarkshavn -1:14:40 - LMT 1916 Jul 28 Zone America/Scoresbysund -1:27:52 - LMT 1916 Jul 28 # Ittoqqortoormiit -2:00 - -02 1980 Apr 6 2:00 -2:00 C-Eur -02/-01 1981 Mar 29 - -1:00 EU -01/+00 + -1:00 EU -01/+00 2024 Mar 31 + -2:00 EU -02/-01 Zone America/Nuuk -3:26:56 - LMT 1916 Jul 28 # Godthåb -3:00 - -03 1980 Apr 6 2:00 -3:00 EU -03/-02 2023 Mar 26 1:00u -- 2.39.2

2 2

Y2K & T2G in the news
by Arthur David Olson Oct. 29, 2023

Oct. 29, 2023

"Y2K bug was real and could have killed says man who found it — here’s when it could hit again" https://nypost.com/2023/10/28/lifestyle/y2k-bug-could-have-killed-heres-whe… @dashdashado

1 0

UNIX epoch on X/Twitter
by Arthur David Olson Oct. 26, 2023

Oct. 26, 2023

A presumably unintended appearance: https://twitter.com/Seth4MC/status/1717535728958062678 @dashdashado

1 0

Invalid POSIX TZ strings in generated TZif files
by Jacob Pratt Oct. 26, 2023

Oct. 26, 2023

The format for POSIX TZ strings is defined here: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#ta… I will note two things from this specification: - The hour shall be between zero and 24 - The *time* has the same format as *offset* except that no leading sign ( '-' or '+' ) is allowed There are four time zones that violate these requirements. - Asia/Gaza has DST transitions that occur 50 hours after midnight (both start and end). - Likewise for Asia/Hebron. - Asia/Jerusalem has a DST transition that begins 26 hours after midnight. - America/Nuuk has a DST transition that begins -1 hours after midnight (not a typo). Violating the first requirement is unspecified behavior, and violating the second is simply not allowed. I ran across these situations while testing a parser for TZif files that I wrote. While the desired behavior is clear, it is also the case that Gaza, Hebron, and Jerusalem rely on unspecified behavior and Nuuk should never parse successfully. Both of these are far from ideal, of course. I'm not entirely certain what can be done here, as the POSIX format is incapable of handling situations like this at first glance. Jacob Pratt

3 3

Re: [tz] Electric Pressure Cooker&Induction Cooker Distributor Needed
by alan＠zsalan.com Oct. 23, 2023

Oct. 23, 2023

1 0

Hard copy of TZdata2023?
by natyaveda Oct. 22, 2023

Oct. 22, 2023

Hey, are you aware of any printable or hard copy (paper) publications of your Time-Zone database in a complete or semi-complete form? Perhaps this has been produced by someone in the astrology community? I'm basically looking to see if its possible to get the rights to include parts of such a publication in a publication of my own. I doubt one exists that includes all the info for every city in the world in a single publication, but I'm looking to see if it does and how large it might be. What I have in mind is something that lists information pretty much exactly as its presented in the tables for the "Detailed time zone and clock changes" available on timeanddate.com (minus everything outside the tables): https://www.timeanddate.com/time/zone/canada/vancouver Thanks for any info you can provide! -James Foyle

8 19

[man]: Bullet lists
by Alejandro Colomar Oct. 22, 2023

Oct. 22, 2023

Hi Paul, I have a small suggestion for formatting of manual pages. Recently, I made lists uniform in the Linux man-pages project, and set some rules for them. See man-pages(7): Lists There are different kinds of lists: ... Bullet lists Elements are preceded by bullet symbols (\[bu]). Anything that doesn’t fit elsewhere is usually covered by this type of list. ... There should always be exactly 2 spaces between the list symbol and the elements. This doesn’t apply to "tagged paragraphs", which use the de‐ fault indentation rules. I guess using '\[bu]' (or '\(bu') might not be appropriate for the tz project, as it may be less portable to old systems, but the 2 spaces between the bullet (the '*' in your case) and the text would be useful. It better distinguishes text from bullets, in the few cases where it may be ambiguous (I didn't check if any may be ambiguous in the tz project). The change would be to use '.IP * 3' instead of '.IP * 2'. 3 is for the width of '*' +2. Would you be interested in such a change? Thanks, Alex -- <https://www.alejandro-colomar.es/>

2 3

[PROPOSED] Document GMT0 and posixrules better
by Paul Eggert Oct. 22, 2023

Oct. 22, 2023

Document the role of /usr/share/zoneinfo/GMT0. Also, improve the documentation for /usr/share/zoneinfo/posixrules. --- date.1 | 14 +++++--------- newctime.3 | 16 ++++++---------- newtzset.3 | 44 +++++++++++++++++++++++++------------------- zic.8 | 12 ++++++------ 4 files changed, 42 insertions(+), 44 deletions(-) diff --git a/date.1 b/date.1 index e8107212..01907bc7 100644 --- a/date.1 +++ b/date.1 @@ -154,15 +154,11 @@ hexadecimal (leading 0x), preceded by an optional sign. .br /usr/lib/locale/\f2L\fP/LC_TIME description of time locale \f2L\fP .br -/usr/share/zoneinfo timezone information directory +/usr/share/zoneinfo timezone directory .br -/usr/share/zoneinfo/posixrules default DST rules (obsolete, - and can cause bugs if present) +/usr/share/zoneinfo/posixrules default DST rules (obsolete) .br /usr/share/zoneinfo/GMT for UTC leap seconds -.sp -If -.B /usr/share/zoneinfo/GMT -is absent, -UTC leap seconds are loaded from -.BR /usr/share/zoneinfo/posixrules . +.PP +If /usr/share/zoneinfo/GMT is absent, +UTC leap seconds are loaded from /usr/share/zoneinfo/GMT0 if present. diff --git a/newctime.3 b/newctime.3 index 05bb7dea..3b54d4ad 100644 --- a/newctime.3 +++ b/newctime.3 @@ -292,20 +292,16 @@ will continue to exist in this form in future releases of this code. .SH FILES .ta \w'/usr/share/zoneinfo/posixrules\0\0'u -/usr/share/zoneinfo timezone information directory +/etc/localtime local timezone file .br -/usr/share/zoneinfo/localtime local timezone file +/usr/share/zoneinfo timezone directory .br -/usr/share/zoneinfo/posixrules default DST rules (obsolete, - and can cause bugs if present) +/usr/share/zoneinfo/posixrules default DST rules (obsolete) .br /usr/share/zoneinfo/GMT for UTC leap seconds -.sp -If -.B /usr/share/zoneinfo/GMT -is absent, -UTC leap seconds are loaded from -.BR /usr/share/zoneinfo/posixrules . +.PP +If /usr/share/zoneinfo/GMT is absent, +UTC leap seconds are loaded from /usr/share/zoneinfo/GMT0 if present. .SH SEE ALSO getenv(3), newstrftime(3), diff --git a/newtzset.3 b/newtzset.3 index 78b6b6ce..80617cd7 100644 --- a/newtzset.3 +++ b/newtzset.3 @@ -306,21 +306,31 @@ The abbreviations for standard and daylight saving time are and .q "\*-02". .PP -If no -.I rule -is present in -.BR TZ , -the rules specified -by the +If +.B TZ +specifies daylight saving time but does not specify a +.IR rule , +and the optional .BR tzfile (5)-format file .B posixrules -in the system time conversion information directory are used, with the -standard and daylight saving time offsets from UT replaced by those specified by -the +is present in the system time conversion information directory, the +rules in +.B posixrules +are used, with the +.B posixrules +standard and daylight saving time offsets from UT +replaced by those specified by the .I offset values in .BR TZ . +However, the +.B posixrules +file is obsolete: if it is present it is only for backward compatibility, +and it does not work reliably. +Therefore, applications that specify a +.B TZ +string with daylight saving time should specify rules explicitly. .PP For compatibility with System V Release 3.1, a semicolon .RB ( ; ) @@ -329,20 +339,16 @@ may be used to separate the from the rest of the specification. .SH FILES .ta \w'/usr/share/zoneinfo/posixrules\0\0'u -/usr/share/zoneinfo timezone information directory +/etc/localtime local timezone file .br -/usr/share/zoneinfo/localtime local timezone file +/usr/share/zoneinfo timezone directory .br -/usr/share/zoneinfo/posixrules default DST rules (obsolete, - and can cause bugs if present) +/usr/share/zoneinfo/posixrules default DST rules (obsolete) .br /usr/share/zoneinfo/GMT for UTC leap seconds -.sp -If -.B /usr/share/zoneinfo/GMT -is absent, -UTC leap seconds are loaded from -.BR /usr/share/zoneinfo/posixrules . +.PP +If /usr/share/zoneinfo/GMT is absent, +UTC leap seconds are loaded from /usr/share/zoneinfo/GMT0 if present. .SH SEE ALSO getenv(3), newctime(3), diff --git a/zic.8 b/zic.8 index c467efef..6bcef7ae 100644 --- a/zic.8 +++ b/zic.8 @@ -121,6 +121,12 @@ will act as if the input contained a link line of the form .ti +.5i Link \fItimezone\fP posixrules .sp +If +.I timezone +is +.q "\*-" +(the default), any already-existing link is removed. +.sp Unless .I timezone is .q "\*-" , @@ -131,12 +137,6 @@ and it should not be combined with if .IR timezone 's transitions are at standard time or Universal Time (UT) instead of local time. -.sp -If -.I timezone -is -.BR \*- , -any already-existing link is removed. .TP .BR "\*-r " "[\fB@\fP\fIlo\fP][\fB/@\fP\fIhi\fP]" Limit the applicability of output files -- 2.41.0

1 0

Re: [tz] Timezone for Brazil
by Guy Harris Oct. 20, 2023

Oct. 20, 2023

On Oct 8, 2023, at 9:56 AM, Fabrício Rennó via tz <tz(a)iana.org> wrote: > Brazil has officially 4 time zones. > Source: http://www.horalegalbrasil.mct.on.br/HoraLegalBrasileira.php > Expected listed results: > - America/Brazil/Noronha(GMT-02:00) > - America/Brazil/Brasilia(GMT-03:00) > - America/Brazil/Amazonas(GMT-04:00) > - America/Brazil/Acre(GMT-05:00) As https://data.iana.org/time-zones/tz-link.html states: Timezones are typically identified by continent or ocean and then by the name of the largest city within the region containing the clocks. Thus, the IANA database timezones in Brazil, just like time zones in the United States and Canada and Mexico and Germany and India and Nigeria and... do not include the name of the country, and almost always contain the name of a city, not the name of a larger region. Furthermore, IANA database timezones don't just correspond to regions that all currently share an offset from UTC/GMT; they handle not only the current official offset from UTC/GMT, they also handle rules from switching between standard time and daylight saving/summer/etc. time, and even handle changes to the *official standard time offset from UTC/GMT* (which sometimes *does* happen). In addition, there may be IANA database timezones that do not correspond to *current* timezones, but that differed from other regions, either in their standard offset from UTC?GMT or in their time-shifting rules, at some point between 1970 and now. Therefore, the IANA database timezones for Brazil are, with identifications taken from comments in the database source (I'm guessing the two-capital-letter codes are codes for states: America/Noronha - Fernando de Noronha (the comments say "administratively part of PE") America/Belem - Amapá (AP), east Pará (PA) America/Santarem - west Pará America/Fortaleza - Maranhão (MA), Piauí (PI), Ceará (CE), Rio Grande do Norte (RN), Paraíba (PB) America/Recife - Pernambuco (PE) (except Atlantic islands) America/Araguaina - Tocantins (TO) America/Maceio - Alagoas (AL), Sergipe (SE) America/Bahia - Bahia (BA) (the comments say "There are too many Salvadors elsewhere, so use America/Bahia instead of America/Salvador.") America/Sao_Paulo - Goiás (GO), Distrito Federal (DF), Minas Gerais (MG), Espírito Santo (ES), Rio de Janeiro (RJ), São Paulo (SP), Paraná (PR), Santa Catarina (SC), Rio Grande do Sul (RS) America/Campo_Grande - Mato Grosso do Sul (MS) America/Cuiaba - Mato Grosso (MT) America/Porto_Velho - Rondônia (RO) America/Boa_Vista - Roraima (RR) America/Manaus - east Amazonas (AM): Boca do Acre, Jutaí, Manaus, Floriano Peixoto (the comments say "The great circle line from Tabatinga to Porto Acre divides east from west Amazonas.") America/Eirunepe - west Amazonas (AM): Atalaia do Norte, Boca do Maoco, Benjamin Constant, Eirunepé, Envira, Ipixuna America/Rio_Branco - Acre (AC) So: 1) more than you list; 2) no "/Brazil" in the names. Results, on my machine, for 2018-08-04 20:42:19 UTC (chosen because its "seconds since the Epoch" value happened to appear in the "date" manual page on my machine): America/Noronha: UTC-02:00 America/Belem, America/Santarem, America/Fortaleza, America/Recife, America/Araguaina, America/Maceio, America/Bahia, America/Sao_Paulo: UTC-03:00 America/Campo_Grande, America/Cuiaba, America/Porto_Velho, America/Boa_Vista, America/Manaus: UTC-04:00 America/Eirunepe, America/Rio_Branco: UTC-05:00 So: America/Noronha is the only IANA database timezone in the Noronha official Brazilian time zone; America/Belem, America/Santarem, America/Fortaleza, America/Recife, America/Araguaina, America/Maceio, America/Bahia, and America/Sao_Paulo are the IANA database timezones in the Brasilia official Brazilian time zone; America/Campo_Grande, America/Cuiaba, America/Porto_Velho, America/Boa_Vista, and America/Manaus are the IANA database timezones in the Amazonas official Brazilian time zone; America/Eirunepe and America/Rio_Branco are the IANA database timezones in the Acre official Brazilian time zone.

7 21

Fwd: [IANA #1283803] Europe/Amsterdam
by Leo Bekhuis Oct. 18, 2023

Oct. 18, 2023

Please also see the forwarded message. ........................................................................................ We have some kind of a short discussion on a timezone. We are looking for the correct answer. *Is Europe/Amsterdam currently an IANA compliant timezone?* We see in the most recent version it is linked backwards to Europe/Brussels But does that means that Europe/Amsterdam is no longer compliant. Is zone.tab an actual representation of all current iana compliant timezones? We read a first comment line "tzdb timezone descriptions (deprecated version)" ---------- Forwarded message --------- From: David Dong via RT <iana-questions(a)iana.org> Date: Mon, Oct 16, 2023 at 6:18 PM Subject: [IANA #1283803] Europe/Amsterdam To: <leo.bekhuis(a)sqills.com> Hi Leo, Thank you for contacting us. We host the Time Zone Database, but updates are made by the Time Zone Coordinator in consultation with the Time Zone mailing list, in accordance with RFC 6557. You may wish to contact the mailing list, tz(a)iana.org, directly to inquire about Europe/Amsterdam. For mailing list information, please see: http://www.iana.org/time-zones Best regards, David Dong IANA Services Sr. Specialist On Fri Oct 13 09:26:53 2023, leo.bekhuis(a)sqills.com wrote: > Hi, > > We have some kind of a short discussion on a timezone. > > We are looking for the correct answer. > > *Is Europe/Amsterdam currently an IANA compliant timezone?* > > We see in the most recent version it is linked backwards to Europe/Brussels > But does that means that Europe/Amsterdam is no longer compliant. > > Is zone.tab an actual representation of all current iana compliant > timezones? > We read a first comment line "tzdb timezone descriptions (deprecated > version)" > > > Thanks > > > > Leo Bekhuis > > > P +31 887 745 570 > [image: Sqills - exceeding expectations] <https://www.sqills.com> > LinkedIn <https://www.linkedin.com/company/sqills> | Facebook > <https://www.facebook.com/Sqills/> | Twitter <https://twitter.com/sqills> > Sqills has been awarded the ISO 9001:2015, 27001:2017, ISAE 3402, and PCI > DSS certification. We take pride in building secure and high quality > software > This e-mail message is intended exclusively for the addressee or addressees > and may contain personal and/or confidential information. If you have > received this message in error, please notify the sender and delete this > message from your system immediately. > We also request that you neither use the contents nor disclose them in any > manner to third parties, because the message may contain information which > is protected by professional secrecy. > -- Leo Bekhuis P +31 887 745 570 [image: Sqills - exceeding expectations] <https://www.sqills.com> LinkedIn <https://www.linkedin.com/company/sqills> | Facebook <https://www.facebook.com/Sqills/> | Twitter <https://twitter.com/sqills> Sqills has been awarded the ISO 9001:2015, 27001:2017, ISAE 3402, and PCI DSS certification. We take pride in building secure and high quality software This e-mail message is intended exclusively for the addressee or addressees and may contain personal and/or confidential information. If you have received this message in error, please notify the sender and delete this message from your system immediately. We also request that you neither use the contents nor disclose them in any manner to third parties, because the message may contain information which is protected by professional secrecy. -- This e-mail message is intended exclusively for the addressee or addressees and may contain personal and/or confidential information. If you have received this message in error, please notify the sender and delete this message from your system immediately. We also request that you neither use the contents nor disclose them in any manner to third parties, because the message may contain information which is protected by professional secrecy.

3 2