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

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

On Wed, Oct 26, 2022 at 08:42:16PM +0700, Robert Elz wrote:
 >     Date:        Wed, 26 Oct 2022 04:16:03 +0000
 >     From:        David Holland <dholland-tech%netbsd.org@localhost>
 >     Message-ID:  <Y1i0g2c3KJLaqpN0%netbsd.org@localhost>
 > 
 >   | Where is this documented?
 > 
 > As much as your message can be construed as a complaint about the
 > documentation, I agree, it should be better.
 > 
 > For most of the rest I'm assuming that you replied to my earliest
 > message in this thread before you read the rest of them.

No?

I don't see how POSIX proposing to define a function to produce a
wrong (and completely meaningless, no less!) answer makes it correct.

 >   | I would expect strftime to print GMT if fed the results of gmtime(),
 >   | and indeed ours does.
 > 
 > As you demonstrated, indeed ours doesn't.   It does produce
 > (not print, strftime() is not an I/O function) what posix
 > is going to require it to produce in this area however.
 > Most of the strftime() conversions are indeed just localised
 > sprintf's (effectively, not literally) of the values in the struct tm,
 > and work whatever is in the tm
 > [...]

Emitting binary representations into a string buffer is a form of
"printing".

But anyway, if this is so, why does it print the wrong timezone? It
seems to be configured to do it wrong on purpose.

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