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

[Robert Elz]

    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.

Sure, while we're distributing the leap seconds raw data, that should be
complete (even if in a different format from the bulletin - distilling
the info from many of them into one place), that's fine.   Keeping the
expiration date there isn't an issue - as long as the bulletins retain it.
When (if) they stop publishing an expiration date (which probably means
no more regular bulletins) then it should be removed from the files that
are distributed with tzdata.

  | We haven't been getting reminders like this recently. I expect this is 
  | because NTPD has declined in popularity.

That, or that recently those files have been being regularly updated.
If there's no need for a new tzdata distribution soon though, I think
you might see requests again, as the ones currently in 2023c are due to
expire in a little over a month.

  | Chrony then uses localtime and mktime to infer leap seconds.

That's kind of bizarre, but whatever they feel is best.

  | Although Oppenlander's patch does not support leap second expiry, it 
  | might be just a matter of time before it adds support for that too.

As long as it is getting it from the leap-seconds file (one of the variants)
that's fine.

  | Internet RFC 8536 specifies a provision for truncating TZif files so 
  | that timestamps after time T are not supported; this is partly to save 
  | space when transmitting them, and partly I assume for the same reason 
  | that leap-seconds.list has an expiration date - some TZif distributors 
  | want to ensure their users get periodic updates.

Perhaps - though anything which fails to convert (as accurately as is
believed possible) any time_t which can be represented in a struct tm
wouldn't be POSIX conformant.   Just stopping at some arbitrary time
isn't permitted.   Obviously everything about the future is just best
guess.   Whether users feel the need for updates or not (ideally of
course, that would simply happen - at least for net connected systems)
is ultimately their choice.

  | 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.

kre