xkcd: Y2K and 2038
https://xkcd.com/2697/

It shouldn't cost more than a trillion dollars or two to investigate this.

Explained at:
https://www.explainxkcd.com/wiki/index.php/2697:_Y2K_and_2038

Lynn

On Saturday, November 12, 2022 at 7:30:00 AM UTC+11, Lynn McGuire wrote:
> xkcd: Y2K and 2038
> https://xkcd.com/2697/
>
> It shouldn't cost more than a trillion dollars or two to investigate this.
>
> Explained at:
> https://www.explainxkcd.com/wiki/index.php/2697:_Y2K_and_2038
..
PL/I uses a double word float.
It handled the Y2K problem with minimal changes to programs.
..
Banks didn't learn anything from Y2K: they still use 2-digit years.

Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
> xkcd: Y2K and 2038
> https://xkcd.com/2697/
>
> It shouldn't cost more than a trillion dollars or two to investigate this.

The switchover to 64-bit systems should have done this. Not sure
that this cost a trillion dollars, but computers usually have a
limited lifetime, so they had to be replaced anyway.

On 11/12/2022 1:36 AM, Thomas Koenig wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>> xkcd: Y2K and 2038
>> https://xkcd.com/2697/
>>
>> It shouldn't cost more than a trillion dollars or two to investigate this.
>
> The switchover to 64-bit systems should have done this. Not sure
> that this cost a trillion dollars, but computers usually have a
> limited lifetime, so they had to be replaced anyway.

Most software is still 32 bit. Having the operating system as 64 bit
helps but it does not solve the problem of the 32 bit software running
on it. An unsigned 32 bit integer only gets us to 2106.
https://en.wikipedia.org/wiki/Year_2038_problem

Porting software to 64 bit is a tremendous work for most software.

Lynn

On Saturday, November 12, 2022 at 6:36:59 PM UTC+11, Thomas Koenig wrote:
> Lynn McGuire <lynnmc...@gmail.com> schrieb:
> > xkcd: Y2K and 2038
> > https://xkcd.com/2697/
> >
> > It shouldn't cost more than a trillion dollars or two to investigate this.
> The switchover to 64-bit systems should have done this. Not sure
> that this cost a trillion dollars, but computers usually have a
> limited lifetime, so they had to be replaced anyway.
..
It requires software to use functions that deal with dates beyond 2038.
..
PL/I already can handle years beyond 2038, as mentioned.
..
BTW, it also requires companies to use 4-digit years.

Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
> On 11/12/2022 1:36 AM, Thomas Koenig wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>> xkcd: Y2K and 2038
>>> https://xkcd.com/2697/
>>>
>>> It shouldn't cost more than a trillion dollars or two to investigate this.
>>
>> The switchover to 64-bit systems should have done this. Not sure
>> that this cost a trillion dollars, but computers usually have a
>> limited lifetime, so they had to be replaced anyway.
>
> Most software is still 32 bit. Having the operating system as 64 bit
> helps but it does not solve the problem of the 32 bit software running
> on it. An unsigned 32 bit integer only gets us to 2106.
> https://en.wikipedia.org/wiki/Year_2038_problem
>
> Porting software to 64 bit is a tremendous work for most software.

UNIX went through that in the mid-nineties to mid-noughties.
It mostly involved cleaning some assumptions about pointer vs. int
size. Clean code was OK from the start, but to lessen the pain,
most operating systems adopted I4LP8 (integers four bytes, longs
and pointers eight bytes).

The important thing was that the interfaces remained constant at
the API level.

I believe what you're discribing is not 32 vs. 64 bit in general,
but rather a peculiarity of Windows which Microsoft inflicted
on its customers because, well, they could.

On Sat, 12 Nov 2022 01:58:44 -0600
Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>On 11/12/2022 1:36 AM, Thomas Koenig wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>> xkcd: Y2K and 2038
>>> https://xkcd.com/2697/
>>>
>>> It shouldn't cost more than a trillion dollars or two to investigate this.
>>
>> The switchover to 64-bit systems should have done this. Not sure
>> that this cost a trillion dollars, but computers usually have a
>> limited lifetime, so they had to be replaced anyway.
>
>Most software is still 32 bit. Having the operating system as 64 bit
>helps but it does not solve the problem of the 32 bit software running
>on it. An unsigned 32 bit integer only gets us to 2106.

I suspect that'll be long enough. The sorts of computers running in 80 years
time will probably bear little resemblence to what we have now.

> https://en.wikipedia.org/wiki/Year_2038_problem
>
>Porting software to 64 bit is a tremendous work for most software.

Not really as long as the programmer hasn't done something stupid like assuming
the size of int or long instead of using int32_t etc.

On 12/11/2022 08:58, Lynn McGuire wrote:
> On 11/12/2022 1:36 AM, Thomas Koenig wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>> xkcd: Y2K and 2038
>>>      https://xkcd.com/2697/
>>>
>>> It shouldn't cost more than a trillion dollars or two to investigate
>>> this.
>>
>> The switchover to 64-bit systems should have done this.  Not sure
>> that this cost a trillion dollars, but computers usually have a
>> limited lifetime, so they had to be replaced anyway.
>
> Most software is still 32 bit.  Having the operating system as 64 bit
> helps but it does not solve the problem of the 32 bit software running
> on it.  An unsigned 32 bit integer only gets us to 2106.
>    https://en.wikipedia.org/wiki/Year_2038_problem
>
> Porting software to 64 bit is a tremendous work for most software.
>

Most *nix software has been 64-bit clean for decades. Most /new/
Windows software is 64-bit clean. A fair bit of modern software on
Windows is cross-platform, sometimes originating in the *nix world, and
that will be fine with 64-bit.

The only PC software that has trouble with 64-bit is Windows software
with a long history, and written with poor code. Code that assumes
pointers fit in longs, or that LONG is a suitable type for holding a
time value, will have trouble. So yes, that kind of software will be a
problem - and some of it will still be in use by 2038.

There will be some local problems within company-specific software - but
there are /always/ problems with company specific software as
requirements change and assumptions are no longer valid. I don't
foresee Y2038 being specially problematic.

For embedded software, this will not be much of an issue. The great
majority of embedded software doesn't have any need of dates or long
timings. For small systems that /do/ need dates or long times, it's
common to have your own formats to keep track - it's far smaller code to
increment a second/minute/hour/day/month/year tracker every second, than
to deal with the mess of leap seconds, locales, and other complications
of converting UNIX epoch to local time.

Also, good embedded developers take overflows into account all the time.
They are more likely to see a 32-bit millisecond counter than a second
counter, and that overflows after 49 days - it is something you
understand and you make sure the code does not fail after 49 days.

My only real concern about Y2038 is excessive paranoia and bureaucracy.
I expect to be inundated with requirements to document that some
flashing light we made in 1990 does not suffer from Y2038 problems.

12.11.2022 09:36 Thomas Koenig kirjutas:
> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>> xkcd: Y2K and 2038
>> https://xkcd.com/2697/
>>
>> It shouldn't cost more than a trillion dollars or two to investigate this.
>
> The switchover to 64-bit systems should have done this. Not sure
> that this cost a trillion dollars, but computers usually have a
> limited lifetime, so they had to be replaced anyway.

64-bit system does not help if the program does not use it. At least
boost xtime used to have 'long' counters, which indeed are 64-bit in
some 64-bit implementations, but not so in others. Not sure about their
current state, I have phased boost::xtime out in preparation for Y2038.

On Saturday, November 12, 2022 at 2:58:50 AM UTC-5, Lynn McGuire wrote:

> ..
>
> Porting software to 64 bit is a tremendous work for most software.

Re: "Porting software to 64 bit is a tremendous work for most software", no this is inaccurate. It is "tremendous work" for *only* certain software that have followed platform-dependent nonportable and other coding practices for far too long that have been flagged as problematic on many forums and literature.

ISO IEC standard-conforming Fortran codes have long worked portably across different versions of 32-bit and 64-bit versions of Microsoft OS, my first experience with one such code was way back in 2010 on 32-bit and 64-bit Windows 7 which gave me my first introduction to the Fortran 2008 standard. That later had me dig deeper into Fortran 2008 followed by Fortran 2015 that eventually got renamed to Fortran 2018.

Lynn McGuire <lynnmcguire5@gmail.com> writes:
>On 11/12/2022 1:36 AM, Thomas Koenig wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>> xkcd: Y2K and 2038
>>> https://xkcd.com/2697/
>>>
>>> It shouldn't cost more than a trillion dollars or two to investigate this.
>>
>> The switchover to 64-bit systems should have done this. Not sure
>> that this cost a trillion dollars, but computers usually have a
>> limited lifetime, so they had to be replaced anyway.
>
>Most software is still 32 bit.

In what year? That's certainly not the case today,
and it will be even less so by 2038.

And how much of that software uses time_t?

On Saturday, November 12, 2022 at 8:05:19 AM UTC-8, Scott Lurndal wrote:
(snip)

> And how much of that software uses time_t?

I suspect that a lot of software uses time_t, but more important,
is where it uses it.

Many compilers, and probably other programs, output a listing file
with the date on top. It won't fail, but will print out the wrong date.

There is a story, many years old by now, of some DEC system that kept dates
with not enough bits. That one had something like make, to decide which files
to compile based on the date last changed. That failed at a surprising time,
but then got fixed, too.

I suspect that by now, most of the important dates are in DBMS systems,
and will automatically, and invisibly, have enough bits.

And Y2K wasn't really as bad as some thought. I do remember a credit card
that didn't work, only once, with expiration date after 2000. That depended on
every individual little terminal, and some were updated slowly. Note that the
actual failure wasn't in the year 2000, though.

gah4 <gah4@u.washington.edu> schrieb:
> On Saturday, November 12, 2022 at 8:05:19 AM UTC-8, Scott Lurndal wrote:
> (snip)
>
>> And how much of that software uses time_t?
>
> I suspect that a lot of software uses time_t, but more important,
> is where it uses it.
>
> Many compilers, and probably other programs, output a listing file
> with the date on top.

It would be interesting to see which current compilers still do this.
VS Fortran probably still does, but it is stuck at FORTRAN 77,
and I can hardly call that "current".

None of the UNIX-oriented compilers do (the tradition was always to
be as quiet as possible), and also not Windows compilers. gfortran
does not even have an option to produce a source listing.

On Saturday, November 12, 2022 at 11:30:18 AM UTC-8, Thomas Koenig wrote:

(snip)

> > Many compilers, and probably other programs, output a listing file
> > with the date on top.

> It would be interesting to see which current compilers still do this.
> VS Fortran probably still does, but it is stuck at FORTRAN 77,
> and I can hardly call that "current".
For the IBM compilers, the default is a sysgen option.
The ones I knew had it on by default, but you can always
turn it off. The option is SOURCE or NOSOURCE.
The LIST and NOLIST options give you the listing
of the generated assembly code, though not in the
form that an assembler will accept.

> None of the UNIX-oriented compilers do (the tradition was always to
> be as quiet as possible), and also not Windows compilers. gfortran
> does not even have an option to produce a source listing.

I haven't thought about it so recently. I thought the usual Unix
compilers would do it, but not by default.

It seems that gcc has options starting with --fdump
to generate various files with (hopefully) useful information,
and which might have dates in them.

gah4 <gah4@u.washington.edu> schrieb:
> On Saturday, November 12, 2022 at 11:30:18 AM UTC-8, Thomas Koenig wrote:

>> None of the UNIX-oriented compilers do (the tradition was always to
>> be as quiet as possible), and also not Windows compilers. gfortran
>> does not even have an option to produce a source listing.
>
> I haven't thought about it so recently. I thought the usual Unix
> compilers would do it, but not by default.
>
> It seems that gcc has options starting with --fdump
> to generate various files with (hopefully) useful information,
> and which might have dates in them.

You can do -fdump-fortran-original to get at the internal syntax
tree, and -fdump-tree-original to see what the Fortran front end
hands to the middle end. It is quite instructive to see what
a simple Fortran statement can result in...

No date information, though.

In article <tknieo$36gkg$2@newsreader4.netcologne.de>,
Thomas Koenig <tkoenig@netcologne.de> wrote:

> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
> > xkcd: Y2K

That's Y2K38.

> > https://xkcd.com/2697/
> >
> > It shouldn't cost more than a trillion dollars or two to investigate this.
>
> The switchover to 64-bit systems should have done this. Not sure
> that this cost a trillion dollars, but computers usually have a
> limited lifetime, so they had to be replaced anyway.

The problem is the all the archival formats that knew 32 bit
would always be enough.

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Chen sockpuppet. insults Islam. Mohammed

In article <tko9lc$168q6$1@dont-email.me>,
Paavo Helde <eesnimi@osa.pri.ee> wrote:

> 12.11.2022 09:36 Thomas Koenig kirjutas:
> > Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
> >> xkcd: Y2K and 2038
> >> https://xkcd.com/2697/
> >>
> >> It shouldn't cost more than a trillion dollars or two to investigate this.
> >
> > The switchover to 64-bit systems should have done this. Not sure
> > that this cost a trillion dollars, but computers usually have a
> > limited lifetime, so they had to be replaced anyway.
>
> 64-bit system does not help if the program does not use it. At least
> boost xtime used to have 'long' counters, which indeed are 64-bit in
> some 64-bit implementations, but not so in others. Not sure about their
> current state, I have phased boost::xtime out in preparation for Y2038.

I use double which gives me subsecond resolution for millions of
years.

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Chen sockpuppet. insults Islam. Mohammed

Lynn McGuire <lynnmcguire5@gmail.com> writes:

> On 11/12/2022 1:36 AM, Thomas Koenig wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>> xkcd: Y2K and 2038
>>> https://xkcd.com/2697/
>>>
>>> It shouldn't cost more than a trillion dollars or two to investigate this.
>> The switchover to 64-bit systems should have done this. Not sure
>> that this cost a trillion dollars, but computers usually have a
>> limited lifetime, so they had to be replaced anyway.
>
> Most software is still 32 bit. Having the operating system as 64 bit
> helps but it does not solve the problem of the 32 bit software running
> on it. An unsigned 32 bit integer only gets us to 2106.
> https://en.wikipedia.org/wiki/Year_2038_problem
>
> Porting software to 64 bit is a tremendous work for most software.

An unsigned time_t makes it impossible to represent times before 1970.
Not all software is going to care about that, but in my opinion it's
an unacceptable price.

There are still 32-bit systems and environments. On my 64-bit Ubuntu
system I can compile with `gcc -m32` and get 32-bit pointers and time_t.

But since C and C++ require support for 64-bit integers anyway, it
should be practical to require 64-bit time_t even on 32-bit systems.
(Not sure about Fortran.)

The real problem is going to be 32-bit (or smaller) embedded systems
whose software can't be updated. On the other hand, a lot of such
systems probably don't care what time it is.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

On Saturday, November 12, 2022 at 6:00:09 PM UTC-8, Keith Thompson wrote:

(snip)

> The real problem is going to be 32-bit (or smaller) embedded systems
> whose software can't be updated. On the other hand, a lot of such
> systems probably don't care what time it is.

As I noted, the only Y2K problem that happened to me was from a credit
card terminal. As I understand it, the terminal checks the date before
sending the request off to the remote system.

However, the problems with smaller systems are smaller.
If one terminal fails, the rest of the system keeps going.

But also, small systems are doing better at being upgradable.

I just found out that the computer system inside our car can be
upgraded through WiFi. It turns out that our home WiFi reaches
out to the street. Just about anything with firmware in flash,
and a USB or network connection, now allows for upgrade.

In comp.lang.fortran Lynn McGuire <lynnmcguire5@gmail.com> wrote:
> xkcd: Y2K and 2038
> https://xkcd.com/2697/
>
> It shouldn't cost more than a trillion dollars or two to investigate this.
>
> Explained at:
> https://www.explainxkcd.com/wiki/index.php/2697:_Y2K_and_2038
>
> Lynn

My contribution to the 2038 problem:

----- o< ---------------------------------------------------
program p2038
! (c) Klaus Wacker
use datesub, only: jd,cdate
implicit none
integer, parameter :: minute=60
integer, parameter :: hour=60*minute
integer, parameter :: day=24*hour
integer, parameter :: maxepoch=(2**30-1)+2**30
integer date_time(8), jdmax, jdnow,jd1970,yyyy,mm,dd
integer secsmax,hoursmax,minsmax,yyyymax,mmmax,ddmax,daysub
integer monthstil
integer until(6)
integer i,ia,is,cnt
character*12 arg,lang
logical test,verbose
character*8, pointer :: texte(:,:)
character*8, target :: de_texte(2,9) = reshape( ['Jahr ','Jahre ','Monat ',&
&'Monate ', 'Tag ','Tage ','Stunde ','Stunden ','Minute ','Minuten ',&
&'Sekunde ','Sekunden','Noch ',' ',' und ',', ','Ende: ',&
&' '], shape(de_texte))
character*8, target :: en_texte(2,9) = reshape( ['year ','years ','month ',&
&'months ', 'day ','days ','hour ','hours ','minute ','minutes ',&
&'second ','seconds ',' ','left ',' and ',', ','The end:',&
&' '], shape(en_texte))
character*5 between
!
test=.false.
verbose=.false.
jd1970=jd(1970,1,1)
call date_and_time(values=date_time)
i=0
do ia=1,iargc()
call getarg(ia,arg)
if(arg.eq."-t") then
test=.true.
else if(arg.eq."-v") then
verbose=.true.
else
! numerical command line values override corresponding date_time values
i=i+1
read(arg,*,err=99) date_time(i)
endif
enddo
! call getenv("LANG",lang)
if(test) write(*,*) "LANG=",lang
if(lang(1:2)=="de") then
texte => de_texte
else
texte => en_texte
endif
! jdnow=jd(date_time(1),date_time(2),date_time(3))
if(test) write(*,*) date_time
jdmax=maxepoch/day+jd1970
secsmax=mod(maxepoch,day)
call hms(hoursmax,minsmax,secsmax)
call cdate(jdmax,yyyymax,mmmax,ddmax)
if(verbose) write(*,'(a,i4.4,a,i2.2,a,i2.2,a,i2.2,a,i2.2,a,i2.2,a)') &
&trim(texte(1,9))//" ",&
&yyyymax,"-",mmmax,"-",ddmax,"-",hoursmax,":",minsmax,":",secsmax," UTC"
until(3)=jdmax-jdnow
until(6)=(jdnow-jd1970)*day - date_time(4)*minute &
& + date_time(5)*hour + date_time(6)*minute + date_time(7)
! this should be the same as $(date +%s)
if(test) write(*,*) until(6)
until(6) = maxepoch - until(6) - until(3)*day
daysub = 0
if(until(6)<0) then
daysub = 1
until(6) = until(6)+day
endif
call hms(until(4),until(5),until(6))
until(1) = yyyymax-date_time(1)
until(3) = jdmax - jd(date_time(1)+until(1),date_time(2),date_time(3)) - daysub
if(until(3)<0) then
until(1) = until(1)-1
! until(3) = jdmax - jd(date_time(1)+until(1),date_time(2),date_time(3)) - daysub
endif
! until(2) cannot be a do variable
do monthstil=11,0,-1
until(3) = jdmax - jd(date_time(1)+until(1) + (date_time(2)+monthstil-1)/12,&
&mod(date_time(2)+monthstil-1,12)+1,date_time(3)) - daysub
if(until(3)>=0) exit
enddo
until(2)=monthstil
cnt = count(until>0)
if(texte(1,7)/=" ") write(*,'(a)',advance="no") trim(texte(1,7))//" "
do i=1,6
if(cnt==2) then
between=texte(1,8)
elseif(cnt==1) then
between=""
else
between=texte(2,8)
endif
if(until(i)/=0) then
is=min(until(i),2)
write(*,'(i0,a)',advance="no") until(i)," "//trim(texte(is,i))//trim(between)//" "
cnt=cnt-1
endif
enddo
write(*,'(a)') trim(texte(2,7))
stop
! 99 write(*,*) "Invalid argument ",ia,": ",arg
stop 1
! contains
subroutine hms(hours,mins,secs)
implicit none
integer, intent(inout) :: secs
integer, intent(out) :: hours,mins
hours=secs/hour
secs=mod(secs,hour)
mins=secs/minute
secs=mod(secs,minute)
end subroutine hms
end program p2038
----- o< ---------------------------------------------------

DATESUB is a piece of software that I got really long time ago via
this newsgroup (with some trivial cahnges in lowercase, mainly to turn
it into a module):

----- o< ---------------------------------------------------
module datesub
contains
SUBROUTINE CALEND(YYYY,DDD,MM,DD)
!=============CALEND WHEN GIVEN A VALID YEAR, YYYY, AND DAY OF THE
! YEAR, DDD, RETURNS THE MONTH, MM, AND DAY OF THE
! MONTH, DD.
! SEE ACM ALGORITHM 398, TABLELESS DATE CONVERSION, BY
! DICK STONE, CACM 13(10):621.
implicit none
INTEGER YYYY,DDD,MM,DD,T
T=0
IF(MOD(YYYY,4).EQ.0) T=1
!-----------THE FOLLOWING STATEMENT IS NECESSARY IF YYYY IS LESS TNAN
! 1900 OR GREATER THAN 2100.
IF(MOD(YYYY,400).NE.0.AND.MOD(YYYY,100).EQ.0) T=0
DD=DDD
IF(DDD.GT.59+T) DD=DD+2-T
MM=((DD+91)*100)/3055
DD=(DD+91)-(MM*3055)/100
MM=MM-2
!----------MM WILL BE CORRECT IFF DDD IS CORRECT FOR YYYY.
IF(MM.GE.1 .AND. MM.LE.12) RETURN
WRITE(*,1) DDD
1 FORMAT('0$$$CALEND: DAY OF THE YEAR INPUT =',I11,' IS OUT OF RANGE.')
STOP
END SUBROUTINE
SUBROUTINE CDATE(JD,YYYY,MM,DD)
!=======GIVEN A JULIAN DAY NUMBER, NNNNNNNN, YYYY,MM,DD ARE RETURNED AS
! AS THE CALENDAR DATE. JD=NNNNNNNN IS THE JULIAN DATE
! FROM AN EPOCK IN THE VERY DISTANT PAST. SEE CACM
! 1968 11(10):657, LETTER TO THE EDITOR BY FLIEGEL AND
! VAN FLANDERN.
! EXAMPLE CALL CDATE(2440588,YYYY,MM,DD) RETURNS 1970 1 1 .
! implicit none
INTEGER JD,YYYY,MM,DD,L,N
L=JD+68569
N=4*L/146097
L=L-(146097*N + 3)/4
YYYY=4000*(L+1)/1461001
L=L-1461*YYYY/4+31
MM=80*L/2447
DD=L-2447*MM/80
L=MM/11
MM=MM + 2 - 12*L
YYYY=100*(N-49) + YYYY + L
RETURN
END SUBROUTINE CDATE
SUBROUTINE DAYSUB(JD,YYYY,MM,DD,WD,DDD)
!========GIVEN JD, A JULIAN DAY # (SEE ASF JD), THIS ROUTINE
! CALCULATES DD, THE DAY NUMBER OF THE MONTH; MM, THE MONTH
! NUMBER; YYYY THE YEAR; WD THE WEEKDAY NUMBER, AND DDD
! THE DAY NUMBER OF THE YEAR.
! ARITHMETIC STATEMENT FUNCTIONS 'IZLR' AND 'IDAY' ARE TAKEN
! FROM REMARK ON ALGORITHM 398, BY J. DOUGLAS ROBERTSON,
! CACM 15(10):918.
! ! EXAMPLE: CALL DAYSUB(2440588,YYYY,MM,DD,WD,DDD) YIELDS 1970 1 1 4 1.
! implicit none
INTEGER JD,YYYY,MM,DD,WD,DDD
integer iday,izlr
! !------IZLR(YYYY,MM,DD) GIVES THE WEEKDAY NUMBER 0=SUNDAY, 1=MONDAY,
! ... 6=SATURDAY. EXAMPLE: IZLR(1970,1,1)=4=THURSDAY
! IZLR(YYYY,MM,DD)=MOD((13*(MM+10-(MM+10)/13*12)-1)/5+DD+77 &
+5*(YYYY+(MM-14)/12-(YYYY+(MM-14)/12)/100*100)/4 &
+ (YYYY+(MM-14)/12)/400-(YYYY+(MM-14)/12)/100*2,7)
! !------IDAY IS A COMPANION TO CALEND; GIVEN A CALENDAR DATE, YYYY, MM,
! DD, IDAY IS RETURNED AS THE DAY OF THE YEAR.
! EXAMPLE: IDAY(1984,4,22)=113
! IDAY(YYYY,MM,DD)=3055*(MM+2)/100-(MM+10)/13*2-91 &
+(1-(MOD(YYYY,4)+3)/4+(MOD(YYYY,100)+99)/100 &
-(MOD(YYYY,400)+399)/400)*(MM+10)/13+DD
! CALL CDATE(JD,YYYY,MM,DD)
WD=IZLR(YYYY,MM,DD)
DDD=IDAY(YYYY,MM,DD)
RETURN
END SUBROUTINE DAYSUB
FUNCTION JD(YYYY,MM,DD)
implicit none
integer jd
INTEGER YYYY,MM,DD
! DATE ROUTINE JD(YYYY,MM,DD) CONVERTS CALENDER DATE TO
! JULIAN DATE. SEE CACM 1968 11(10):657, LETTER TO THE
! EDITOR BY HENRY F. FLIEGEL AND THOMAS C. VAN FLANDERN.
! EXAMPLE JD(1970,1,1)=2440588
JD=DD-32075+1461*(YYYY+4800+(MM-14)/12)/4 &
+367*(MM-2-((MM-14)/12)*12)/12-3* &
((YYYY+4900+(MM-14)/12)/100)/4
RETURN
END FUNCTION JD
FUNCTION NDAYS(MM1,DD1,YYYY1, MM2,DD2,YYYY2)
implicit none
integer ndays
INTEGER YYYY1,MM1,DD1,YYYY2,MM2,DD2
!==============NDAYS IS RETURNED AS THE NUMBER OF DAYS BETWEEN TWO
! DATES; THAT IS MM1/DD1/YYYY1 MINUS MM2/DD2/YYYY2,
! WHERE DATEI AND DATEJ HAVE ELEMENTS MM, DD, YYYY.
!-------NDAYS WILL BE POSITIVE IFF DATE1 IS MORE RECENT THAN DATE2.
NDAYS=JD(YYYY1,MM1,DD1)-JD(YYYY2,MM2,DD2)
RETURN
END FUNCTION NDAYS
end module datesub
----- o< ---------------------------------------------------

In comp.lang.fortran Klaus Wacker <klaus.w.wacker@t-online.de> wrote:
>
> My contribution to the 2038 problem:
>

[program text deleted]

Of course you are welcome to add languages.

--
Klaus Wacker klaus.w.wacker@t-online.de
51°29'7"N 7°25'7"E

On 11/12/2022 6:00 PM, Keith Thompson wrote:
> On the other hand, a lot of such
> systems probably don't care what time it is.

Why am I thinking of Chicago now?

On 13/11/2022 03:00, Keith Thompson wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>
>> On 11/12/2022 1:36 AM, Thomas Koenig wrote:
>>> Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
>>>> xkcd: Y2K and 2038
>>>> https://xkcd.com/2697/
>>>>
>>>> It shouldn't cost more than a trillion dollars or two to investigate this.
>>> The switchover to 64-bit systems should have done this. Not sure
>>> that this cost a trillion dollars, but computers usually have a
>>> limited lifetime, so they had to be replaced anyway.
>>
>> Most software is still 32 bit. Having the operating system as 64 bit
>> helps but it does not solve the problem of the 32 bit software running
>> on it. An unsigned 32 bit integer only gets us to 2106.
>> https://en.wikipedia.org/wiki/Year_2038_problem
>>
>> Porting software to 64 bit is a tremendous work for most software.
>
> An unsigned time_t makes it impossible to represent times before 1970.
> Not all software is going to care about that, but in my opinion it's
> an unacceptable price.

For the solid majority of programs that use Unix epoch times, unsigned
would be fine. There can't be many programs that need dates before 1970
but are happy to think the world started in late 1901 - Unix epoch times
are almost always considered as time after 01.01.1970. However, as long
as there are /some/ programs that need negative epoch times, you can't
break that functionality.

>
> There are still 32-bit systems and environments. On my 64-bit Ubuntu
> system I can compile with `gcc -m32` and get 32-bit pointers and time_t.
>

I think I heard that the next Ubuntu would not have 32-bit libraries in
its normal repositories any more. That won't stop them being available
for those that need them. (I think I only need 32-bit libraries on
Linux in connection with Wine and 32-bit Windows programs.)

More modern Linux (since kernel 5.6, according to Wikipedia) systems
have 64-bit time_t even on 32-bit builds.

> But since C and C++ require support for 64-bit integers anyway, it
> should be practical to require 64-bit time_t even on 32-bit systems.

Yes.

> (Not sure about Fortran.)

(That's better than me - I haven't a clue about Fortran!)

>
> The real problem is going to be 32-bit (or smaller) embedded systems
> whose software can't be updated. On the other hand, a lot of such
> systems probably don't care what time it is.
>

Pretty much any non-trivial embedded system will care a bit about time,
but usually only relative time - blink every second, send a message
every hour, or whatever. These might have a 32-bit second counter, but
are more likely to have millisecond counters or higher resolution. And
they generally take overflow into account by simply subtracting start
times and current times (generally assuming two's complement wrapping
overflow...). Millisecond 32-bit counters overflow after 49 days, so it
is something you think about more than 69 year overflows.

Small embedded systems which also track the date will generally not do
so using Unix epoch timestamps - it's a lot easier to hold a structure
with second, minute, hour, day, month, year fields and update it. That
avoids all the mess of locales and time and date conversions.

Bigger embedded systems are more likely to be updatable - though that
does not mean they /will/ be updated. Manufacturers might provide
updates for a few years or while the product is still being made and
sold, but after that they may not bother.

There will be some systems that are a problem - but I do not expect it
to be a widespread issue.

In article <tkrao1$1ghql$1@redfloyd.dont-email.me>,
red floyd <no.spam.here@its.invalid> wrote:
>On 11/12/2022 6:00 PM, Keith Thompson wrote:
>> On the other hand, a lot of such
>> systems probably don't care what time it is.
>
>Why am I thinking of Chicago now?
>

03:35, 03;34, whatever...

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Voltaire

On Monday, November 14, 2022 at 1:09:40 AM UTC-8, David Brown wrote:

(snip)

> Small embedded systems which also track the date will generally not do
> so using Unix epoch timestamps - it's a lot easier to hold a structure
> with second, minute, hour, day, month, year fields and update it. That
> avoids all the mess of locales and time and date conversions.

Reminds me that I have a sprinkler timer that you program with the year.
It needs the year because you can set it to water on even or odd days,
and so has to get leap years right.

But if it watered on the wrong day, it wouldn't be the worst thing.

You can program it by week days, then it doesn't even need the month,
but you still have to set year and month.