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: Thomas Klausner <wiz%netbsd.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost
Subject: Re: lib/60452: gmtime, gmtime_r put wrong time zone into result
Date: Fri, 17 Jul 2026 04:22:38 +0700

     Date:        Thu, 16 Jul 2026 20:46:25 +0200
     From:        Thomas Klausner <wiz%netbsd.org@localhost>
     Message-ID:  <alkmgRfoTh5e8iLo%exadelic.gatalith.at@localhost>
 
   | macOS:
   | ./test.sh: line 3: 53331 Segmentation fault: 11  TZ=Etc/GMT+7 ./jq
   | ./test.sh: line 4: 53332 Segmentation fault: 11  ./jq
   |
   | Debian:
   | Segmentation fault
   | Segmentation fault
   |
   | FreeBSD:
   | In-address space security exception (core dumped)
   | In-address space security exception (core dumped)
 
 Then they're all just using tm_zone, which means a properly conforming
 C application is likely to fail, as it cannot init that field, all it
 can do is leave random stack garbage in its place if it uses strftime
 to format a date/time which it has (for example) parsed into a struct
 tm from some other source (and it uses strftime %Z - which the C standard
 does define).
 
 The trash init of the tm_zone field I added to jq.c, and you tested, was
 just to simulate that random stack garbage, which gmtime() would never
 leave, but which alternate code to fill the struct tm would have no option
 but to do (using memset() as that code does would help, but is not a
 requirement).
 
 Perhaps that is acceptable, I'm not sure.   Using the tm_gmtoff and
 tm_zone fields certainly makes strftime much simpler to implement.
 
 kre