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

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

    Date:        Sat, 5 Nov 2022 19:16:28 +0000
    From:        Taylor R Campbell <campbell+netbsd-tech-userlevel%mumble.net@localhost>
    Message-ID:  <20221105191644.4D1AE6033C%jupiter.mumble.net@localhost>

  | I'm not sure this is adequately specified either.

I'm sure it isn't, the strftime(3) man page is crap.   That part
I never doubted.   The mktime entry in what is really ctime(3) isn't
much better.

  | This could mean several things:
  |
  | 1. strftime_z interprets the struct tm relative to tz, and formats it
  |    in tz.

That is the one it means, which I think is clear from the details I
gave about their implementations.   Everything ends up calling strftime_lz()
strftime() calls it with the default locale, and default timezone
(created by tzset() so it will always be the TZ or /etc/localtime zone)
strftime_l() substitutes the locale passed as an arg for the default one,
strftime_z() substitutes the timezone passed as an arg for the default one,
and strftime_lz() just does everything using the locale and timezone passed
to it.

strftime_lz() is what really produced all of the results that have been
discussed, there has never been a locale issue, the default locale was
used in all examples, so that part can be ignored for now.  When called
via strftime() (which is what has been happening) the local time (for
dh@ America/New_York) timezone was being used, and explains the answers
obtained.   Substitute a different one, and different answers appear
(for those strftime() conversions for which the zone influences the result).

These might, or might not, be enough for what people want, it is
hard to know what is really wanted/needed without a real application.
But there is enough there already that one can certainly design a new
interface to achieve almost anything required, as part of an application,
or if something were to have general enough appeal, to be added to one
of the libraries.

One thing to beware of though, is that there is not enough info in a
struct tm to determine which timezone created it.   It simply cannot
(in general) be done.   Changing struct tm (however appealing that
might be - and believe me, I would really like to) is not practical.
For a specialised purpose, a new struct, containing a struct tm, and
also whatever extra data is required, could be designed & used of course.

kre