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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 26 Oct 2022 22:08:50 +0000
    From:        David Holland <dholland-tech%netbsd.org@localhost>
    Message-ID:  <Y1mv8u6LDXirZ60o%netbsd.org@localhost>

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

The answer is neither wrong nor meaningless, it simply doesn't
do what you might have wanted it to do.   For typical uses (I use %s
all the time, generally via "date +%s") it works exactly as intended.
It also works when used as "date -u +%s" (both of these uses might have
a -r or -d option to set the time desired, rather than just "now"), as
date -u is set up to use UTC correctly.

Further, what POSIX is doing (it is already in the drafts) is specifying
what the implementations (including ours, and glibc) actually do.  That's
what the users should expect to happen.

If you want something different, implement that, and then get the rest
of the implementations to actually adopt it - and then propose it to
POSIX, you never know, it might appear in the standard following the
next one (in another 5-10 years).

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

I will look into the timezone stuff in strftime(), but from when I glanced
at it yesterday, it seemed to be simply using what is in the struct tm,
passed in, so it may be that gmtime() isn't putting something useful in
those fields (after all, if you're using gmtime() you ought to know that
the zone name is GMT or UTC (your pick) and that the offset is 0).   It
is also perhaps affected by tm_isdst, which I assume gmtime() always sets
to 0.

It would help if you shared the "./test" program you used (source, doesn't
matter how crufty - I understand quick and dirty tests) so I can reproduce
your results.

kre