From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0DF883858410; Fri, 17 Dec 2021 07:45:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0DF883858410 From: "jb at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libfortran/98507] timezone is incorrect on last day of year for "TZ" hours Date: Fri, 17 Dec 2021 07:45:35 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libfortran X-Bugzilla-Version: 8.3.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jb at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Dec 2021 07:45:36 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98507 Janne Blomqvist changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jb at gcc dot gnu.org --- Comment #5 from Janne Blomqvist --- (In reply to anlauf from comment #1) > Not a confirmation, just an observation: libgfortran/intrinsics/time_1.h > prefers gettimeofday over clock_gettime, whereas the Linux manpages have: >=20 > GETTIMEOFDAY(2) Linux Programmer's Manual=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20 > GETTIMEOFDAY(2) >=20 > CONFORMING TO > SVr4, 4.3BSD. POSIX.1-2001 describes gettimeofday() but not= =20 > settimeofday(). > POSIX.1-2008 marks gettimeofday() as obsolete, recommending the u= se > of clock_get- > time(2) instead. >=20 >=20 > Janne chose this prioritization in 2012, but there is no comment explaini= ng > his choice. Should this be revisited? Usage of gettimeofday() was, and still is, ubiquitous. In find it hard to imagine any C library would remove it just because POSIX has deprecated it, unless they want a significant fraction of applications to stop working. That being said, my main motivation for preferring gettimeofday() was that = back then clock_gettime was not found in the glibc libc.so but rather in librt (which is part of glibc, but not linked by default for single-threaded programs). See the weakref trickery in intrinsics/system_clock.c for how us= ing clock_gettime on glibc < 2.17 was done, where there was a real motivation f= or using clock_gettime, namely to access the monotonic clock. So preferring gettimeofday() in time_1.h:gf_gettime() meant that as many targets as possi= ble used the same code path as glibc targets, reducing the risk of target-speci= fic bugs that I would have difficulty deciphering considering I was developing = on Linux myself. However, this is all water under the bridge by now, as clock_gettime is par= t of glibc libc.so since glibc 2.17. So I think switching the order now in 2021 = is perfectly fine. As an additional datapoint, per https://man7.org/linux/man-pages/man7/vdso.7.html all Linux targets that provide gettimeofday() as a VDSO also provide clock_gettime() as a VDSO, so= no concerns there either. As a minor nit, now that clock_gettime() is the "main" implementation for gf_gettime() you might want to change it to return nanoseconds rather than microseconds, and update the callers.=