Robert Elz via tz wrote in <3221.1701295665@jacaranda.noi.kre.to>: | Date: Wed, 29 Nov 2023 11:28:00 -0800 | From: Paul Eggert <eggert@cs.ucla.edu> | Message-ID: <2cfab05c-3580-4172-a412-525c43f75298@cs.ucla.edu> | || As you may recall, a few years ago the tz list was periodically asked by || downstream users to update the leap-seconds.list file, even when that || file's list of leap seconds did not change. ... || Chrony then uses localtime and mktime to infer leap seconds. | |That's kind of bizarre, but whatever they feel is best. They use mktime and gmtime: tm = gmtime(&when); if (!tm) return tz_leap; stm = *tm; /* Temporarily switch to the timezone containing leap seconds */ tz_env = getenv("TZ"); if (tz_env) { if (strlen(tz_env) >= sizeof (tz_orig)) return tz_leap; strcpy(tz_orig, tz_env); } setenv("TZ", leap_tzname, 1); tzset(); /* Get the TAI-UTC offset, which started at the epoch at 10 seconds */ t = mktime(&stm); if (t != -1) tz_tai_offset = t - when + 10; /* Set the time to 23:59:60 and see how it overflows in mktime() */ stm.tm_sec = 60; stm.tm_min = 59; stm.tm_hour = 23; t = mktime(&stm); if (tz_env) setenv("TZ", tz_orig, 1); else unsetenv("TZ"); tzset(); if (t == -1) return tz_leap; if (stm.tm_sec == 60) tz_leap = LEAP_InsertSecond; else if (stm.tm_sec == 1) tz_leap = LEAP_DeleteSecond; *tai_offset = tz_tai_offset; Wouldn't it have been nice if the world would have gone on distributing TAI and simply the offset to UTC, instead of anything else. (And an indicator, smart people outperform me with ideas there.) Btw chrony says /* Allow leap second only on the last day of June and December */ and i am not sure this is correct. I noted for this response that ISO C 23 has no match for TZ nor timezone. Nor putenv / setenv / unsetenv. ... || However, after RFC 8536 || came out we discovered that this truncation provision in some sense || collides with leap second expiry: should a truncated table mean that || leap seconds expire too? or vice versa? | |If localtime() were really refusing to convert times, then who cares? |If not, then there is no real expiration date in the file, just a lack |of future data, for when it matters. I think bets can be taken whether they do the switch before the negative leap, shall it occur, or not. On another list i said (after that decision) all the troubles will happen and then it is thrown apart saying "good it is gone", .. instead of trying to do something to make working with it smooth, for which several decades of opportunities exist(ed). I have negative feelings with it being thrown off, "i said", as mankind went for thousands of years to be able to get it right, and it was magic, it was a miracle, it was a shining laugther, and now we can, intellectually penetrated even, like our friend the Californian astronomer (also in this list) with all his bells and whistles (it is a science), and throw it away because of false business decisions. (I think nothing should be done. For dates 1972-X leap second information will hold forever, unless you blur it off.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)