https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123693
Bug ID: 123693
Summary: year 2038 for time functions (gmtime, ltime)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: manfred99 at gmx dot ch
Target Milestone: ---
Approaching year 2038 (exactly 12 years to go), date functions
should be allowed to work correctly with 64bit integer types,
at least on 64bit archs.
Consider
program gmtime_test
INTEGER i,year,maxday,daynumber,hour,timearr(9)
CC INTEGER stime
INTEGER(8) stime
year=2039
daynumber=10
hour=12
stime=0
DO i=1970,year-1
IF (i.EQ.i/4*4) THEN
maxday=366
ELSE
maxday=365
ENDIF
stime=stime+maxday
ENDDO
stime=stime+daynumber-1
stime=stime*24+hour
stime=stime*3600
CALL gmtime(stime,timearr)
timearr(6)=timearr(6)+1900
timearr(5)=timearr(5)+1
print*,timearr
CALL ltime(stime,timearr)
timearr(6)=timearr(6)+1900
timearr(5)=timearr(5)+1
print*,timearr
end
This gives
#> gfc-16 gmtime_test.f
25 | CALL gmtime(stime,timearr)
| 1
Error: 'time' argument of 'gmtime' intrinsic at (1) must be of kind 4
gmtime_test.f:30:17:
30 | CALL ltime(stime,timearr)
| 1
Error: 'time' argument of 'ltime' intrinsic at (1) must be of kind 4
However, these functions seem to already work correctly using
default-integer-8:
#> gfc-16 gmtime_test.f -fdefault-integer-8
#> ./gmtime_test
0 0 12
10 1 2039 1
9 0
0 0 13
10 1 2039 1
9 0
So, the functions seem to work, they just needlessly reject
an integer(8) argument. So one should simply zap the integer check, I think.
Surprisingly, the function ctime() is not affected, it works flawlessly
with integer(8).
