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

["Thomas Klausner via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR lib/60452; it has been noted by GNATS.

From: Thomas Klausner <wiz%netbsd.org@localhost>
To: Robert Elz <kre%munnari.oz.au@localhost>
Cc: netbsd-bugs%netbsd.org@localhost
Subject: Re: lib/60452: gmtime, gmtime_r put wrong time zone into result
Date: Thu, 16 Jul 2026 19:38:14 +0200

 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