On Jan 12, 2024, at 11:47 AM, Steve Summit via tz <tz@iana.org> wrote:
But, despite their non-human-readableness, time_t values are now so ubiquitous that they are occasionally of interest to humans, so at some point along the way, the 'date' command acquired "%s" as one of its custom output format specifiers.
At some point, *somebody's* "date" command may have acquired "%s", but it's not in issue 7 of POSIX/SUS.
I gather from this thread that someone has decided to "solve" this problem anyway, by officially adding %s to the supported strftime formats. However, it seems to me that the only "problem" here is that the 'date' program has been difficult to write. My own opinion is that dragging the whole rest of the world through this mudpit is not the right way of solving date's implementation problem -- but then, I'm not on the Posix committee, so it doesn't matter what I think.
From looking at the POSIX 8 draft, %s was added to strftime() as a result of Austin Group Defect 169. That defect noted that there's no POSIX-compliant way to, in a shell script, get a string that's the numerical value of the current time_t, and requested a "%s" output format identifier for the date command, rather than, say, a "-e" (for "Epoch") command-line flag. The result of the discussion for that defect was that %s should be added to strftime().