[Bug fortran/98507] New: timezone is incorrect on last day of year for "TZ" hours

[Bug fortran/98507] New: timezone is incorrect on last day of year for "TZ" hours

[urbanjost at comcast dot net]

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.

[Bug libfortran/98507] timezone is incorrect on last day of year for "TZ" hours

[anlauf at gcc dot gnu.org]

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?

[Bug libfortran/98507] timezone is incorrect on last day of year for "TZ" hours

[fxcoudert at gcc dot gnu.org]

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.

[Bug libfortran/98507] timezone is incorrect on last day of year for "TZ" hours

[fxcoudert at gcc dot gnu.org]

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

[Bug libfortran/98507] timezone is incorrect on last day of year for "TZ" hours

[urbanjost at comcast dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507

--- Comment #4 from urbanjost at comcast dot net ---
Thanks! nice to have this fixed!

[Bug libfortran/98507] timezone is incorrect on last day of year for "TZ" hours

[jb at gcc dot gnu.org]

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.