public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/98507] New: timezone is incorrect on last day of year for "TZ" hours
@ 2021-01-04 2:25 urbanjost at comcast dot net
2021-01-05 21:26 ` [Bug libfortran/98507] " anlauf at gcc dot gnu.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: urbanjost at comcast dot net @ 2021-01-04 2:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507
Bug ID: 98507
Summary: timezone is incorrect on last day of year for "TZ"
hours
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: urbanjost at comcast dot net
Target Milestone: ---
Created attachment 49870
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49870&action=edit
call date_and_time and print timezone
On the last day of the year if your timezone is not GMT the timezone value
returned by the intrinsic DATE_AND_TIME is incorrect until the local date is
the first of the year.
That is, from 9PM till midnight on the 2020-12-31 a huge timezone value was
returned that was actually a year off in minutes. On a Red Hat 8 machine this
can be duplicate by setting the system time to 2200 (10PM) on 2020-12-31.
date
/home/urbanjs/venus/V600/bin/Linux_gfortran/bug
date 123122002020.00
/home/urbanjs/venus/V600/bin/Linux_gfortran/bug
exit
Sun Jan 3 21:07:57 EST 2021
2021 1 3 -300 21 7 57 208
-0500
2021 1 3 -300 21 7 57 208
Thu Dec 31 22:00:00 EST 2020
2020 12 31***** 22 0 0 20
+8779
2020 12 31***** 22 0 0 20
Thu Dec 31 22:00:00 EST 2020
2020 12 31 526740 22 0 0
13
+8779
2020 12 31 526740 22 0 0
13
So in the EST timezone it is only incorrect during the last five hours of the
year.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libfortran/98507] timezone is incorrect on last day of year for "TZ" hours
2021-01-04 2:25 [Bug fortran/98507] New: timezone is incorrect on last day of year for "TZ" hours urbanjost at comcast dot net
@ 2021-01-05 21:26 ` anlauf at gcc dot gnu.org
2021-12-16 9:58 ` fxcoudert at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: anlauf at gcc dot gnu.org @ 2021-01-05 21:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507
anlauf at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|fortran |libfortran
--- Comment #1 from anlauf at gcc dot gnu.org ---
Not a confirmation, just an observation: libgfortran/intrinsics/time_1.h
prefers gettimeofday over clock_gettime, whereas the Linux manpages have:
GETTIMEOFDAY(2) Linux Programmer's Manual
GETTIMEOFDAY(2)
CONFORMING TO
SVr4, 4.3BSD. POSIX.1-2001 describes gettimeofday() but not
settimeofday().
POSIX.1-2008 marks gettimeofday() as obsolete, recommending the use of
clock_get-
time(2) instead.
Janne chose this prioritization in 2012, but there is no comment explaining
his choice. Should this be revisited?
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libfortran/98507] timezone is incorrect on last day of year for "TZ" hours
2021-01-04 2:25 [Bug fortran/98507] New: timezone is incorrect on last day of year for "TZ" hours urbanjost at comcast dot net
2021-01-05 21:26 ` [Bug libfortran/98507] " anlauf at gcc dot gnu.org
@ 2021-12-16 9:58 ` fxcoudert at gcc dot gnu.org
2021-12-16 16:50 ` fxcoudert at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2021-12-16 9:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507
Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fxcoudert at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed| |2021-12-16
Status|UNCONFIRMED |NEW
--- Comment #2 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Confirmed, the logic in gcc/libgfortran/intrinsics/date_and_time.c is faulty:
values[3] = (local_time.tm_min - UTC_time.tm_min +
60 * (local_time.tm_hour - UTC_time.tm_hour +
24 * (local_time.tm_yday - UTC_time.tm_yday)));
yday will wrap near the new year, giving rise to those huge values. Patch
incoming.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libfortran/98507] timezone is incorrect on last day of year for "TZ" hours
2021-01-04 2:25 [Bug fortran/98507] New: timezone is incorrect on last day of year for "TZ" hours urbanjost at comcast dot net
2021-01-05 21:26 ` [Bug libfortran/98507] " anlauf at gcc dot gnu.org
2021-12-16 9:58 ` fxcoudert at gcc dot gnu.org
@ 2021-12-16 16:50 ` fxcoudert at gcc dot gnu.org
2021-12-16 17:29 ` urbanjost at comcast dot net
2021-12-17 7:45 ` jb at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2021-12-16 16:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507
Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
Target Milestone|--- |12.0
--- Comment #3 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Fixed at
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3f624a624a137860e080fc959d7467a76aab263d
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libfortran/98507] timezone is incorrect on last day of year for "TZ" hours
2021-01-04 2:25 [Bug fortran/98507] New: timezone is incorrect on last day of year for "TZ" hours urbanjost at comcast dot net
` (2 preceding siblings ...)
2021-12-16 16:50 ` fxcoudert at gcc dot gnu.org
@ 2021-12-16 17:29 ` urbanjost at comcast dot net
2021-12-17 7:45 ` jb at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: urbanjost at comcast dot net @ 2021-12-16 17:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507
--- Comment #4 from urbanjost at comcast dot net ---
Thanks! nice to have this fixed!
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libfortran/98507] timezone is incorrect on last day of year for "TZ" hours
2021-01-04 2:25 [Bug fortran/98507] New: timezone is incorrect on last day of year for "TZ" hours urbanjost at comcast dot net
` (3 preceding siblings ...)
2021-12-16 17:29 ` urbanjost at comcast dot net
@ 2021-12-17 7:45 ` jb at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: jb at gcc dot gnu.org @ 2021-12-17 7:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507
Janne Blomqvist <jb at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jb at gcc dot gnu.org
--- Comment #5 from Janne Blomqvist <jb at gcc dot gnu.org> ---
(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:
>
> GETTIMEOFDAY(2) Linux Programmer's Manual
> GETTIMEOFDAY(2)
>
> CONFORMING TO
> SVr4, 4.3BSD. POSIX.1-2001 describes gettimeofday() but not
> settimeofday().
> POSIX.1-2008 marks gettimeofday() as obsolete, recommending the use
> of clock_get-
> time(2) instead.
>
>
> Janne chose this prioritization in 2012, but there is no comment explaining
> 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 using
clock_gettime on glibc < 2.17 was done, where there was a real motivation for
using clock_gettime, namely to access the monotonic clock. So preferring
gettimeofday() in time_1.h:gf_gettime() meant that as many targets as possible
used the same code path as glibc targets, reducing the risk of target-specific
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 part 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-12-17 7:45 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-04 2:25 [Bug fortran/98507] New: timezone is incorrect on last day of year for "TZ" hours urbanjost at comcast dot net
2021-01-05 21:26 ` [Bug libfortran/98507] " anlauf at gcc dot gnu.org
2021-12-16 9:58 ` fxcoudert at gcc dot gnu.org
2021-12-16 16:50 ` fxcoudert at gcc dot gnu.org
2021-12-16 17:29 ` urbanjost at comcast dot net
2021-12-17 7:45 ` jb at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).