Re: pending/60452: gmtime, gmtime_r put wrong time zone into result (pending)

"Christos Zoulas via gnats" <[email protected]>
Newsgroups gmane.os.netbsd.bugs
Message-ID <[email protected]>
The following reply was made to PR lib/60452; it has been noted by GNATS.

From: Christos Zoulas <[email protected]>
To: "[email protected]" <[email protected]>
Cc: NetBSD Problem Report DB Administrator <[email protected]>
Subject: Re: pending/60452: gmtime, gmtime_r put wrong time zone into result
 (pending)
Date: Thu, 16 Jul 2026 14:25:13 -0400

 --Apple-Mail=_6C252C7D-66FF-40B3-8267-B2E481E5D4AE
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/plain;
 	charset=utf-8
 
 
 
 On Jul 16, 2026, at 1:20=E2=80=AFPM, Christos Zoulas =
 <[email protected]> wrote:
 
 This is fixed by removing:
 
 diff -u -p -u -r1.60 strftime.c
 --- strftime.c  8 Mar 2026 21:04:54 -0000       1.60
 +++ strftime.c  16 Jul 2026 17:18:41 -0000
 @@ -53,17 +53,6 @@ __RCSID("$NetBSD: strftime.c,v 1.60 2026
 
 #include "private.h"
 
 -/*
 -** We don't use these extensions in strftime operation even when
 -** supported by the local tzcode configuration.  A strictly
 -** conforming C application may leave them in undefined state.
 -*/
 -
 -#ifdef _LIBC
 -#undef TM_ZONE
 -#undef TM_GMTOFF
 -#endif
 -
 
 Because without these extensions strftime does not have a way to
 determine the timezone in struct tm and defaults to what the current
 timezone.
 
 I think we should remove, because the current behavior is unexpected
 and this is what everyone else does (BSD, MacOS, Linux)
 
 christos
 
 
 --Apple-Mail=_6C252C7D-66FF-40B3-8267-B2E481E5D4AE
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/html;
 	charset=utf-8
 
 <html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" =
 content=3D"text/html; charset=3Dutf-8"></head><body =
 style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
 line-break: after-white-space;"><br =
 id=3D"lineBreakAtBeginningOfMessage"><div><br><div>On Jul 16, 2026, at =
 1:20=E2=80=AFPM, Christos Zoulas &lt;[email protected]&gt; =
 wrote:</div><blockquote type=3D"cite"></blockquote><div><font =
 color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
 214);"><br></span></font></div><div>This is fixed by =
 removing:</div><div><font color=3D"#5856d6"><span style=3D"caret-color: =
 rgb(88, 86, 214);"><br></span></font></div><div>diff -u -p -u -r1.60 =
 strftime.c</div><div>--- strftime.c &nbsp;8 Mar 2026 21:04:54 -0000 =
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1.60</div><div>+++ strftime.c =
 &nbsp;16 Jul 2026 17:18:41 -0000</div><div>@@ -53,17 +53,6 @@ =
 __RCSID("$NetBSD: strftime.c,v 1.60 2026</div><div><font =
 color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
 214);"><br></span></font></div><div>#include "private.h"</div><div><font =
 color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
 214);"><br></span></font></div><div>-/*</div><div>-** We don't use these =
 extensions in strftime operation even when</div><div>-** supported by =
 the local tzcode configuration. &nbsp;A strictly</div><div>-** =
 conforming C application may leave them in undefined =
 state.</div><div>-*/</div><div>-</div><div>-#ifdef =
 _LIBC</div><div>-#undef TM_ZONE</div><div>-#undef =
 TM_GMTOFF</div><div>-#endif</div><div>-</div><div><font =
 color=3D"#5856d6"><span style=3D"caret-color: rgb(88, 86, =
 214);"><br></span></font></div><div>Because without these extensions =
 strftime does not have a way to</div><div>determine the timezone in =
 struct tm and defaults to what the =
 current</div><div>timezone.</div><div><font color=3D"#5856d6"><span =
 style=3D"caret-color: rgb(88, 86, 214);"><br></span></font></div><div>I =
 think we should remove, because the current behavior is =
 unexpected</div><div>and this is what everyone else does (BSD, MacOS, =
 Linux)</div><div><br></div><div><div>christos<br></div></div></div><br></b=
 ody></html>=
 
 --Apple-Mail=_6C252C7D-66FF-40B3-8267-B2E481E5D4AE--
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.