[tz] If leap seconds go away, should TZif leap-second tables expire?

[Steffen Nurpmeso]

Robert Elz via tz wrote in
 <3221.1701295665 at jacaranda.noi.kre.to>:
 |    Date:        Wed, 29 Nov 2023 11:28:00 -0800
 |    From:        Paul Eggert <eggert at cs.ucla.edu>
 |    Message-ID:  <2cfab05c-3580-4172-a412-525c43f75298 at 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)