The year 2038 problem may cause some computer software to fail at some point near the year 2038. The problem affects all software and systems that both store system time as a signed 32-bit integer, and interpret this number as the number of seconds since 00:00:00 UTC on Thursday, 1 January 1970.[1] The furthest time that can be represented this way is 03:14:07 UTC on Tuesday, 19 January 2038.[2] Times beyond this moment will “wrap around” and be stored internally as a negative number, which these systems will interpret as a date in 1901 rather than 2038. This is caused by integer overflow. The counter “runs out” of usable digits, “increments” the sign bit instead, and reports a maximally negative number (continuing to count up, toward zero). This is likely to cause problems for users of these systems due to erroneous calculations.
I think this a little premature don’t you?
Apart from the fact that I’ll probably be 6’ under. So it really won’t bother me. I’m dead sure about that.
But I’m pretty confident the world of tech will have moved on by then, to another dimension. What we have now will be soooo ‘yesterday’.
Not to mention that we’ll either have destroyed the world ourselves or some higher power will intervene.
I am not too fancy with computers. Is this something built into the system clock or would the operating system handle this? I doubt anyone will be using 32-bit by 2038.
This is nothing new… It is known since the Unix epoch was “invented” back in the seventies.
And as the old Unix gurus are allways right, it is sure we will have the end of the world then. In any case Kernighan and Ritchie have a higher degree of creditablilty then the Mayas for me.
initial design simply specified an arbitrary [time-out](http://en.wikipedia.org/wiki/Timeout_%28computing%29) date in the future. The default configuration for the server specified that the request should time out after one billion seconds. One billion seconds (approximately thirty-two years) after 9:27.28 pm on 12 May 2006 is beyond the 2038 cutoff date. Thus, after this time, the time-out calculation overflowed and returned a date that was actually in the past, causing the software to crash
>> store system time as a signed 32-bit integer
> I am not too fancy with computers. Is this something built into the
> system clock or would the operating system handle this? I doubt anyone
> will be using 32-bit by 2038.
The system clock is a software thing maintained by the operating system…
–
Cheers / Saludos,
Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))
it is not only he clock itself (and it may even be 64 bit on 64 bit systems), it are the time stamps that are stored a a 32-bit integer everywhere in the system where a time stamp is needed. In your file system for every file’s last time of access, last time of change to give some examples.
On 2013-01-19 22:36, hcvv wrote:
> it is not only he clock itself (and it may even be 64 bit on 64 bit
> systems), it are the time stamps that are stored a a 32-bit integer
> everywhere in the system where a time stamp is needed. In your file
> system for every file’s last time of access, last time of change to give
> some examples.
Yes, absolutely. And every piece of software.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))
> This is nothing new… It is known since the Unix epoch was “invented”
> back in the seventies.
> And as the old Unix gurus are allways right, it is sure we will have the
> end of the world then. In any case Kernighan and Ritchie have a higher
> degree of creditablilty then the Mayas for me.
And - the hype leading up to it will cause more problems then the date
itself. Just like last time.
It’s defined as a signed integer, so it doesn’t look like a problem for 64-bit systems. Wikipedia has this to say:
At 15:30:08 UTC on Sun, 4 December 292,277,026,596 64-bit versions of the Unix time stamp will cease to work, as it will overflow the largest value that can be held in a signed 64-bit number. This is considerably longer than the time it will take the Sun to expand to a red giant and swallow the earth.
As I tried to explain, a 64-bit system does not guarantee storage in 64 bits integers in file systems and other places.
But once that is in place (ext6 ) we will be save.
True indeed, but I see time stamps as a separate problem, only God knows how to fix them, considering the ever increasing need for granularity. Maybe add a GUID to them?
Again this issue may require massive change in coding of timestamps in all programs.
migration of data in databases to newer 64 bit sized and it will cause migration errors. Some may end up with zero balances in their account . The last thing we need.
The problem may also happen in 64 bit systems where someone installs 32 bit JVM on a 64 bit system (WoW64).
i don’t know whether 32 bit jvms will even install on Linux based machines . Probably it won’t. Unless someone puts a 32 bit VM and installs it at the top of it
I think i should pull out all my money from my bank and store it under ground
The Previous Y2K non-event did allow a lot of new Windows software to be sold around my office and numerous HVAC system upgrades. But I saw no catastrophes as I recall. So I am not worried about anything 25 years into the future as I have already been using a computer for the last 34 years, starting my reliable TRS-80 Desktop, 16 K Basic and Audio Tape Loader Interface. My present computer is nearly twice as fast and would allow me to make notes to place flowers out for those of us no longer seated at ground level.
On 2013-01-23 04:26, jdmcdaniel3 wrote:
>
> The Previous Y2K non-event did allow a lot of new Windows software to be
> sold around my office and numerous HVAC system upgrades. But I saw no
> catastrophes as I recall.
I did.
The company I was working for sold a lot of hardware and software with
the excuse of the Y2K effect. The next year it sold next to nothing,
because everybody had overspent their budgets. The investors thought
that the company had lost money, and there was a scare. The shares
dropped from about 80$ to 8$ in a week. Before a year had passed, a
third of the employees worldwide were fired, and another third the next
year, about 100Kpeople.
That I say is a catastrophe. For me and several of my friends it was,
and many have not recovered.
It is a sore and touchy subject for me
–
Cheers / Saludos,
Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))
On 1/22/2013 9:26 PM, jdmcdaniel3 wrote:
>
<snip>
> starting my reliable TRS-80 Desktop, 16 K Basic and Audio Tape
> Loader Interface. My present computer is nearly twice as fast and
> would allow me to make notes to place flowers out for those of us no
> longer seated at ground level.
>
> Thank You,
>
>
jdmcdaniel3;
Are you sure on “twice as fast”? The Z80 chip ran at about 1.8 MHz, modern
chips are 3-5GHz. That’s 2-3 thousand times faster. For me I learned to
program on a CDC3600, circa 1963. Of course it wasn’t mine.
By 2038 I’ll be 95 so my obit could be wrong.
–
P.V.
“We’re all in this together, I’m pulling for you” Red Green
) we will be save.