Re: lib/60452: gmtime, gmtime_r put wrong time zone into result

On Fri, Jul 17, 2026 at 12:23:14AM +0100, Robert Elz wrote:
> The problem you're seeing is from tzcode's attempt to obey the C
> standard when it comes to %z and %Z conversions - according to which
> the values that are in tm_zone and tm_gmtoff cannot be used to generate
> those values - that's because those fields aren't required in C (they
> are now in POSIX) and so a conforming application can't set them.
> 
> The strftime() implementation doesn't know (cannot possibly know) whether
> the struct tm passed to it was generated by localtime/gmtime, or hand
> crafted as in "tm.tm_secs = 33; tm.tm_hour = 2; ...." - in the former
> it could reasonably expect tm_gmtoff and tm_zone to be set.  In the latter
> it cannot, they may simply be uninit'd stack garbage.
> 
> All that strftime() has to rely upon in those cases are the "timezone"
> and "altzone" variables, which gmtime() doesn't set, they always reflect
> the offsets for the local timezone.

Thank you, that was interesting.

As a data point, I tried the same test problem (s/uint64_t/time_t) on
macOS Tahoe, FreeBSD 15, and Debian forky, and on those systems, I get
the result I expected with my test program.

So I tend to agree with christos' suggestion of changing strftime()'s
behaviour.
 Thomas