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

    Date:        Thu, 16 Jul 2026 17:40:01 +0000 (UTC)
    From:        "Thomas Klausner via gnats" <[email protected]>
    Message-ID:  <[email protected]>

  |  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.)