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

[David Holland <dholland-tech%netbsd.org@localhost>]

On Tue, Nov 01, 2022 at 05:20:17AM +0700, Robert Elz wrote:
 > [a small book]

You can rehash the same points over and over again, and continue to
introduce irrelevant distractions, and continue to assert without
evidence that correct behavior is impossible, but the various facts
remain:

(a) It follows from the observations so far that if I set ->tm_gmtoff
to 101 and ->tm_zone to "abracadabra" (as well as populating the rest
of the structure), and ask strftime to print those fields, it will not
print them but print something else. I continue to fail to see how
this is anything other than a bug. Similarly, if I ask it to print
%s, it will bring the wrong time_t value. I continue to fail to see
how *this* is anything other than a bug.

(b) Our implementation contains the timezone info in struct tm. This
does not make our implementation noncompliant; the current posted text
says "The <time.h> header shall declare the tm structure, which shall
include at least the following members:", not "exactly the following
members". It follows (I can find no text to contradict this) that
consing up your own struct tm to call strftime without bzeroing it
first risks producing undefined behavior and is therefore incorrect.

(c) Consequently it's easy to construct a compliant implementation
that contains tm_gmtoff and tm_zone in struct tm and where strftime
behaves correctly with respect to these values for %z, %Z, and %s.
(Whether our implementation can be corrected without a compat mess is
less clear.)

(d) It is, in general, quite easy to write standards language that
acceps both full correct and less than ideal implementations for cases
where the incorrect implementations cannot be fixed. In fact, the
current posted text says:
 : If a struct tm broken-down time structure is created or modified by
 : gmtime() or gmtime_r(), it is unspecified whether the result of the
 : %Z and %z conversion specifiers shall refer to UTC or the current
 : local timezone, when strftime() is called with such a broken-down
 : time structure.
That is more specific than I had suggested, but clearly completely
suitable. (And given this text, I completely fail to understand why
they are proposing to change things.)

(e) Standardization that precludes a correct implementation, or that
mandates an incorrect implementation, remains wrong and inappropriate.

Meanwhile we've clearly reached the point where you're wilfully
misinterpreting what I'm writing in order to dismiss it, not to
mention introducing specious analogies and committing a couple other
rhetorical fouls. So I have a feeling that nothing productive is
likely to happen going forward.

-- 
David A. Holland
dholland%netbsd.org@localhost