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

Groups > comp.lang.c > #168147 > unrolled thread

xkcd: Y2K and 2038

Back to article view | Back to comp.lang.c

Contents

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

#168147 — xkcd: Y2K and 2038

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

[toc] | [next] | [standalone]

#168152

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.

[toc] | [prev] | [next] | [standalone]

#168153

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

[toc] | [prev] | [next] | [standalone]

#168154

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.

[toc] | [prev] | [next] | [standalone]

#168155

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.

[toc] | [prev] | [next] | [standalone]

#168156

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.

[toc] | [prev] | [next] | [standalone]

#168158

On 12/11/2022 10:29, David Brown wrote:
> 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 size of C 'int' on the Windows and Linux systems I have encountered 
still seems to be stuck on 32 bits.

Which means people lazily using that instead of `int64_t` etc, or using 
is as a "don't care" type, are continuing to perpetuate 32-bit-dominated 
software.

> 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.

It is the 'long' type that is problematic. On Windows that is at least 
consistently 32 bits on Win32 and Win64 systems. If you assume it is the 
same size as `void*`, you will quickly discover it isn't on Win64.

On Linux, I think it is 32 bits on Linux32 and 64 bits on Linux64, so 
any assumptions about it there will have more subtle consequences.

[toc] | [prev] | [next] | [standalone]

#168159

On 12/11/2022 12:03, Bart wrote:
> On 12/11/2022 10:29, David Brown wrote:
>> 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 size of C 'int' on the Windows and Linux systems I have encountered 
> still seems to be stuck on 32 bits.
> 
> Which means people lazily using that instead of `int64_t` etc, or using 
> is as a "don't care" type, are continuing to perpetuate 32-bit-dominated 
> software.

There's nothing wrong with using 32-bit types.  The problem only comes 
when you use a 32-bit type for something that might not fit in 32 bits. 
So if there are people using "int" for "time_t", pointers, or other 
things that are unsuitable, then that's a problem.

Otherwise, it's fine to use 32-bit types for 32-bit values.  It is often 
/better/, because it makes better use of cache (obviously this matters 
most for arrays) and memory bus bandwidth, it can be faster for some 
operations, and allows more use of SIMD operations.

> 
>> 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.
> 
> It is the 'long' type that is problematic. On Windows that is at least 
> consistently 32 bits on Win32 and Win64 systems. If you assume it is the 
> same size as `void*`, you will quickly discover it isn't on Win64.

Windows programmers were used to assuming that "long" meant "32-bit", 
and that "long" was the same size as pointers.  MS could only make one 
of these assumptions remain when they moved to 64-bit - they picked the 
wrong one.  (It was especially wrong given that their C compiler didn't 
support C99 and "long long int" at the time, and had no proper 64-bit 
integer type!)

> 
> On Linux, I think it is 32 bits on Linux32 and 64 bits on Linux64, so 
> any assumptions about it there will have more subtle consequences.
> 

In the *nix world, programmers have /long/ been used to avoiding such 
assumptions.  The idea of having everything as a single platform that 
never changes, so you can pretend the basic C types have particular 
fixed characteristics, or assume platform endianness, or strong memory 
models - that's all from the DOS/Windows world.  You can't blame Linux 
for the problems MS caused by picking solutions that are different from 
everyone else, or caused by DOS/Windows programmers writing crap code 
for decades.

[toc] | [prev] | [next] | [standalone]

#168161

On 12/11/2022 11:57, David Brown wrote:
> On 12/11/2022 12:03, Bart wrote:
>> On 12/11/2022 10:29, David Brown wrote:
>>> 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 size of C 'int' on the Windows and Linux systems I have 
>> encountered still seems to be stuck on 32 bits.
>>
>> Which means people lazily using that instead of `int64_t` etc, or 
>> using is as a "don't care" type, are continuing to perpetuate 
>> 32-bit-dominated software.
> 
> There's nothing wrong with using 32-bit types.

I think there is. You would question code, running on a PC where 'int' 
was i32, that specifically used int16_t everywhere for parameters, 
return types, and individual global and local variables for no 
particular reason.

Since it's not really going to save space.

Outside of C, I would only use an i32 type for the same reason I might 
choose i16 or i8: to optimise storage and layout for arrays and structs, 
or as the target of a pointer into such a structure.

Otherwise there is little point on a 64-bit system where registers and 
stack slots are 64 bits anyway. Especially as a 32-bit int is 4 billion 
times more likely to overflow.

[toc] | [prev] | [next] | [standalone]

#168162

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?

[toc] | [prev] | [next] | [standalone]

#168165

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

[toc] | [prev] | [next] | [standalone]

#168170

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?

[toc] | [prev] | [next] | [standalone]

#168179

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

[toc] | [prev] | [next] | [standalone]

#168178

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.

[toc] | [prev] | [next] | [standalone]

#168186

David Brown <david.brown@hesbynett.no> schrieb:
> On 13/11/2022 03:00, Keith Thompson wrote:

>> 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!)

Fortran has the DATE_AND_TIME inrinsic, which returns the the date
and time in calendar format, either as YYYYMMDD and HHMMSS.SSS and
[+/-] HHMM for the zoneif you chose character arguments, or as an
array of integer with the same info.

The library is supposed to take care of how to get the value
from the operating system, user programs need not bother.

There are also non-standard extensions which mimic system
behavior, but those should be avoided, at least in new code.

[toc] | [prev] | [next] | [standalone]

#168185

In comp.lang.fortran Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
[...]
> 
> 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.
>

I read somewhere that the reason for a signed time_t was mainly that
this type was nor just used for time stamps, but also for time
differences.

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

[toc] | [prev] | [next] | [standalone]

#168160

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.

[toc] | [prev] | [next] | [standalone]

#168164

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

[toc] | [prev] | [next] | [standalone]

#168163

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

[toc] | [prev] | [next] | [standalone]

#168167

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




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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web