Re: xkcd: Y2K and 2038

From	Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups	comp.lang.fortran, comp.lang.c, comp.lang.c++
Subject	Re: xkcd: Y2K and 2038
Date	2022-11-12 18:00 -0800
Organization	None to speak of
Message-ID	<87mt8vlila.fsf@nosuchdomain.example.com> (permalink)
References	<tkmbc4$uc0u$1@dont-email.me> <tknieo$36gkg$2@newsreader4.netcologne.de> <tknjnl$k9o$1@gioia.aioe.org>

Cross-posted to 3 groups.

Show all headers | View raw

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 */

Thread

xkcd: Y2K and 2038 Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-11 14:29 -0600
  Re: xkcd: Y2K and 2038 Thomas Koenig <tkoenig@netcologne.de> - 2022-11-12 07:36 +0000
    Re: xkcd: Y2K and 2038 Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-12 01:58 -0600
      Re: xkcd: Y2K and 2038 Thomas Koenig <tkoenig@netcologne.de> - 2022-11-12 08:30 +0000
      Re: xkcd: Y2K and 2038 Muttley@dastardlyhq.com - 2022-11-12 10:00 +0000
      Re: xkcd: Y2K and 2038 David Brown <david.brown@hesbynett.no> - 2022-11-12 11:29 +0100
        Re: xkcd: Y2K and 2038 Bart <bc@freeuk.com> - 2022-11-12 11:03 +0000
          Re: xkcd: Y2K and 2038 David Brown <david.brown@hesbynett.no> - 2022-11-12 12:57 +0100
            Re: xkcd: Y2K and 2038 Bart <bc@freeuk.com> - 2022-11-12 15:56 +0000
        Re: xkcd: Y2K and 2038 Michael S <already5chosen@yahoo.com> - 2022-11-12 10:05 -0800
      Re: xkcd: Y2K and 2038 scott@slp53.sl.home (Scott Lurndal) - 2022-11-12 16:05 +0000
      Re: xkcd: Y2K and 2038 Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-12 18:00 -0800
        Re: xkcd: Y2K and 2038 red floyd <no.spam.here@its.invalid> - 2022-11-13 09:49 -0800
          Re: xkcd: Y2K and 2038 gazelle@shell.xmission.com (Kenny McCormack) - 2022-11-14 09:14 +0000
        Re: xkcd: Y2K and 2038 David Brown <david.brown@hesbynett.no> - 2022-11-14 10:09 +0100
          Re: xkcd: Y2K and 2038 Thomas Koenig <tkoenig@netcologne.de> - 2022-11-14 14:09 +0000
        Re: xkcd: Y2K and 2038 Klaus Wacker <klaus.w.wacker@t-online.de> - 2022-11-14 13:47 +0000
    Re: xkcd: Y2K and 2038 Paavo Helde <eesnimi@osa.pri.ee> - 2022-11-12 16:13 +0200
      Re: xkcd: Y2K and 2038 Siri Cruise <chine.bleu@yahoo.com> - 2022-11-12 15:49 -0700
    Re: xkcd: Y2K and 2038 Siri Cruise <chine.bleu@yahoo.com> - 2022-11-12 15:47 -0700
  Re: xkcd: Y2K and 2038 Klaus Wacker <klaus.w.wacker@t-online.de> - 2022-11-13 12:45 +0000

csiph-web