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

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

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

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: wiz%NetBSD.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: lib/60452: gmtime, gmtime_r put wrong time zone into result
Date: Fri, 17 Jul 2026 01:40:46 +0700

     Date:        Thu, 16 Jul 2026 17:40:01 +0000 (UTC)
     From:        "Thomas Klausner via gnats" <gnats-admin%NetBSD.org@localhost>
     Message-ID:  <20260716174001.E69BF1A923C%mollari.NetBSD.org@localhost>
 
   |  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.
 
 There are two explanations, perhaps they make gmtime() set the magic
 global variables, which I think is permitted, any call to any of
 gmtime() localtime() ctime() or asctime() is allowed to alter the
 static state environment of any of the others, though I wouldn't be
 surprised if there was software out there which assume that doesn't
 happen.   Or they are using the tm_zone and tm_gmtoff fields of the
 struct tm in strftime().
 
 It is easy to test which that is, simply make the f_gmtime() function
 in your test be:
 
 void f_gmtime(time_t secs, struct tm *tmp) {
   memset(tmp, 0, sizeof(*tmp));
   if (gmtime_r(&secs, tmp) == NULL)
     err(1, "gmtime_r failed");
   tmp->tm_gmtoff = -1234;
   tmp->tm_zone = (char *)-1234;
 }
 
 and see what the effect is on those systems.
 
   |  So I tend to agree with christos' suggestion of changing strftime()'s
   |  behaviour.
 
 Sorry, I haven't seen that, so I'm not sure what kind of change he
 meant.   If there was an easy solution to this, which would work
 everywhere, then tzcode would already have it.
 
 The simple solution is not to expect %z or %Z to work after gmtime(),
 and to fix anything which does.   But there might be lots of that, perhaps.
 
 kre
 
 ps: and yes, I forgot in my earlier message, that I also changed the
 type of epoch_secs in main() in jq.c to time_t ... assuming that whatever
 it was, and time_t, are the same type is insane (but so is simply init'int
 a time_t to an constant which is supposed to mean something on a standard C
 system - it works on POSIX, now finally. though.)