Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.fortran > #73930

Re: xkcd: Y2K and 2038

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.lang.fortran, comp.lang.c, comp.lang.c++
Subject Re: xkcd: Y2K and 2038
Date 2022-11-12 11:29 +0100
Organization A noiseless patient Spider
Message-ID <tknsj2$15ad4$2@dont-email.me> (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

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.

Back to comp.lang.fortran | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

xkcd: Y2K and 2038 Lynn McGuire <lynnmcguire5@gmail.com> - 2022-11-11 14:29 -0600
  Re: xkcd: Y2K and 2038 Robin Vowels <robin.vowels@gmail.com> - 2022-11-11 20:31 -0800
  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 FortranFan <parekhvs@gmail.com> - 2022-11-12 06:49 -0800
      Re: xkcd: Y2K and 2038 scott@slp53.sl.home (Scott Lurndal) - 2022-11-12 16:05 +0000
        Re: xkcd: Y2K and 2038 gah4 <gah4@u.washington.edu> - 2022-11-12 10:46 -0800
          Re: xkcd: Y2K and 2038 Thomas Koenig <tkoenig@netcologne.de> - 2022-11-12 19:30 +0000
            Re: xkcd: Y2K and 2038 gah4 <gah4@u.washington.edu> - 2022-11-12 11:56 -0800
              Re: xkcd: Y2K and 2038 Thomas Koenig <tkoenig@netcologne.de> - 2022-11-12 23:45 +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 gah4 <gah4@u.washington.edu> - 2022-11-12 18:08 -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 gah4 <gah4@u.washington.edu> - 2022-11-14 01:54 -0800
            Re: xkcd: Y2K and 2038 Gary Scott <garylscott@sbcglobal.net> - 2022-11-14 09:41 -0600
          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 Robin Vowels <robin.vowels@gmail.com> - 2022-12-02 05:53 -0800
    Re: xkcd: Y2K and 2038 Robin Vowels <robin.vowels@gmail.com> - 2022-11-12 00:02 -0800
    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
    Re: xkcd: Y2K and 2038 Klaus Wacker <klaus.w.wacker@t-online.de> - 2022-11-13 13:23 +0000

csiph-web