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