[tz] strftime %s

[Steve Summit]

Paul wrote:
> On 2024-01-14 06:20, Steve Summit wrote:
>> strftime %s really does have no choice but to do a mktime()
>> based on barely-adequate information -- and part of that
>> information is, alas, the global TZ environment variable.
>
> Although that's one interpretation of the standard, it's not the only 
> one. As I've been saying, although the POSIX and C standards can easily 
> be misinterpreted, they have a better interpretation which says that on 
> a system with tm_gmtoff and tm_zone strftime need not use mktime or 
> equivalent, not even for %s.

I need to go back and read some of the other messages in this
thread, and in particular your arguments in favor of this "other
interpretation".  Here's the use case I'm worried about.  Suppose
someone wants to write some code to take a human-readable local
date/time, and convert it back to a time_t value.  Once upon a
time there was one way to do that: stuff the human-readable
components into a struct tm, and call mktime().  But now there's
an alternative: take the same struct tm, and hand it to strftime
with a format of %s.  (That's a strange, alternative way of doing
it, that I at least would never think of, but once strftime %s
exists, I can't say that it's wrong.)

In either case, however, the programmer probably isn't going to
want to, may not be able to, might well have no idea how to,
compute and fill in the tm_gmtoff field.  (Asking the caller
to fill that in for this case -- much less the hypothetical
tm_time_t field I was suggesting earlier -- is basically
"begging the question".)  So I (somewhat reluctantly) come to
the same conclusion Robert Elz has, namely that mktime can't look
at tm_gmtoff, and that strftime %s can't, either.

>> callers *are* allowed to pass handcrafted struct tm values to
>> strftime, and implementors are obliged to make this work
>
> Yes, but the standards give leeway as to how to "make this work"
> for %z  and %Z, and this leeway includes using members like
> tm_gmtoff and  tm_zone that the C standard does not specify.

Ugh.  Yes, %z and %Z are nasty, too.  (It took me years to get
around to adding them to the strftime equivalent in my own,
homebrew date/time library, and now I'm going to have to go
back and see how baldly I might have assumed that the incoming
broken-down time struct wasn't hand-constructed.)

>> (Which brings me back to my conclusion that %s
>> shouldn't exist, because it's impossible to implement correctly.
>
> It's impossible only if one uses a too-strict interpretation of the 
> standards.

I was wrong when I said "it's impossible".  For one thing,
I had forgotten about TZ, which of course *does* allow %s to
be computed, reasonably correctly, even without tm_gmtoff.
(For another, I was using "correctly" in a broader sense, trying
to include certain additionally woolly-headed quasirequirements
that I keep wanting to impose on %s, even though Robert Elz has
been doggedly trying to remind me that they're no requirements
at all.)