Re: strftime(3) oddities with %s, %z

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 25 Oct 2022 12:56:02 -0400 (EDT)
    From:        Mouse <mouse%Rodents-Montreal.ORG@localhost>
    Message-ID:  <202210251656.MAA01547%Stone.Rodents-Montreal.ORG@localhost>

  | But I see no need to bother with agreement.

Perhaps not, but something this important is more likely to get
used if it has been accepted by more than just its inventor.

  | Sometimes "what works now" is
  | broken enough, or inconsistent enough, that standards do invent new
  | things.  Occasionally, even, we get good standards that way.

Yes, that occasionally happens, but it really should be kept as
a last resort.   This is not one of those cases (and if it were,
the strftime() conversion char would need to be something different
than 's' because of the existing implementations - and finding
something suitable and available, would not be easy).

  | ...??  You're concerned about the interface design lasting past
  | Gregorian 34737 (or 2147485617, if you abandon <32-bit ints)?

I am more concerned that any time_t value can be converted to a
struct whatever, without overflowing the year field, which is not
true now.   That's important, so things like fsck (even stat(1))
can print out what is in a time field, in a rational format, even
when the inode has bee trampled all over by garbage - rather than
either dumping core, or resorting to printing the time_t as an
integer.   Being able to map time_t -> struct whatever is a necessary
step for that to work.

I don't see any particular urgent need for time_t to ever exceed 64
bits (integer part at least, if it were implemented as a float,
which posix doesn't permit but I think C does, or as a fixedpoint,
then probably more) but the broken down form should be able to
represent anything that a time_t can hold (and ideally, anything a
timespec or bintime can hold).   It is less important that any
struct whatever set of values can be converted to a time_t - both
because it is possible to represent things there (in non UTC zones)
which have no equivalent time_t (the time simply did not exist), and
because that direction has always been one where the value can end
up being out of range ... both POSIX and our doc still contain an
error code defined to mean exactly that, yet with the current type
definitions, it can no longer happen.

kre