Home > Archive > Cobol > March 2008 > The next Y2K: Y2.038K bug
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
The next Y2K: Y2.038K bug
|
|
| Robin Lee 2008-03-15, 6:56 pm |
| http://www.switched.com/2008/03/14/...ernet-will-end/
The Unix 2038 bug probably isn't news to some. But it reminds me of the prevalent
attitude ten years ago, that COBOL programmers were negligent or "lazy" for taking
shortcuts with dates. I'm guessing that in 1970 no one thought we'd be using UNIX in
the next century.
| |
| Robert 2008-03-15, 6:56 pm |
| On Sat, 15 Mar 2008 10:19:26 -0400, Robin Lee <robinlee@news.com> wrote:
>http://www.switched.com/2008/03/14/...ernet-will-end/
>
>The Unix 2038 bug probably isn't news to some. But it reminds me of the prevalent
>attitude ten years ago, that COBOL programmers were negligent or "lazy" for taking
>shortcuts with dates. I'm guessing that in 1970 no one thought we'd be using UNIX in
>the next century.
Unix's system timer has a window 1970 through 2037 for positive values and 1901 through
1969 for negative values. It is stored in an unsigned int, which has 31 bits of data and
a sign. The timer resolution is one second. There are 2^31 seconds in 68 years.
There is no easy fix for two reasons:
1. It is not practical to upgrade the operating system in embedded processors,
such as in car engines, medical devices, telephones.
2. Some have used timer_t format in files and messages. Any change would 'break'
old software and file data.
Operating systems compiled to 64 bits store the time as a 63-bit long int, which can
represent billions of years. Records and messages using timer_t must be reformatted. Going
to an unsigned integer would buy 68 years, but break dates before 1970 e.g. your birth
date. A sliding window would be unacceptable because the recipient of messages and records
would not know where the creator's epoch began.
Who cares? We'll be gone by 2038. :)
| |
| Pete Dashwood 2008-03-15, 6:56 pm |
|
"Robert" <no@e.mail> wrote in message
news:n7dot3h2c8kahcckj1gm612pl6j2o4nunh@
4ax.com...
> On Sat, 15 Mar 2008 10:19:26 -0400, Robin Lee <robinlee@news.com> wrote:
>
>
> Unix's system timer has a window 1970 through 2037 for positive values and
> 1901 through
> 1969 for negative values. It is stored in an unsigned int, which has 31
> bits of data and
> a sign. The timer resolution is one second. There are 2^31 seconds in 68
> years.
>
> There is no easy fix for two reasons:
> 1. It is not practical to upgrade the operating system in embedded
> processors,
> such as in car engines, medical devices, telephones.
> 2. Some have used timer_t format in files and messages. Any change would
> 'break'
> old software and file data.
>
> Operating systems compiled to 64 bits store the time as a 63-bit long int,
> which can
> represent billions of years. Records and messages using timer_t must be
> reformatted. Going
> to an unsigned integer would buy 68 years, but break dates before 1970
> e.g. your birth
> date. A sliding window would be unacceptable because the recipient of
> messages and records
> would not know where the creator's epoch began.
>
> Who cares? We'll be gone by 2038. :)
>
Speak for yourself.
If you can't take it with you, I ain't going...:-)
Pete.
--
"I used to write COBOL...now I can do anything."
>
| |
| Mickey 2008-03-25, 6:56 pm |
|
Pete Dashwood wrote:
> "Robert" <no@e.mail> wrote in message
> news:n7dot3h2c8kahcckj1gm612pl6j2o4nunh@
4ax.com...
> Speak for yourself.
>
> If you can't take it with you, I ain't going...:-)
Ditto, I worked too hard for it all.
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."
I always could do anything, I'm a Rexx coder :)
Mickey
| |
|
| On Tue, 25 Mar 2008 11:48:11 -0700, Mickey wrote:
> I always could do anything, I'm a Rexx coder :)
>
> Mickey
Last time I tried it, REXX was appallingly slow and CPU-intensive. Has
that changed?
Tim
|
|
|
|
|