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

[Taylor R Campbell <campbell+netbsd-tech-userlevel%mumble.net@localhost>]

> Date: Sun, 06 Nov 2022 17:22:22 +0700
> From: Robert Elz <kre%munnari.OZ.AU@localhost>
> 
> 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.

I don't think that's needed for what uwe@ and dholland@ were looking
for, which -- if I understand correctly -- is that:

	struct tm gtm, ltm;
	char gbuf[128], lbuf[128];

	gmtime_r(&t, &gtm);
	localtime_r(&t, &ltm);
	strftime_XXX(gbuf, sizeof(gbuf), "... %s ...", &gtm);
	strftime_XXX(lbuf, sizeof(lbuf), "... %s ...", &ltm);

should format the same number at %s in the output (i.e., the value of
t), but otherwise format the broken-down time (%Y/m/d/H/M/S/...)
according to UTC for gtm and the local time for ltm, i.e. just format
the .tm_* members -- and %z should format .tm_gmtoff, which is +0000
for gtm but the local offset for ltm.

After all, these struct tm objects are supposed to represent the same
moment in time (t), just phrased in different civil time zones.  So %s
should be the same for both, and %z should identify the UTC offset
that enables all the other broken-down time components to be
interpreted correctly to give the same moment in time.

I believe there is already enough information stored in struct tm to
do this for everything except perhaps %Z (but %Z doesn't seem to be
very well-specified anyway).  It's not clear to me if you can get this
semantics out of strftime_z but I suspect not.