Run for the hills... (1998/03/12)

Run for the hills...

Posted by Daniel Celano on 1998/03/12 13:07

What was the name of that film where there were two planets on a
collision course for Earth and the first one hit while the USA set up a
colony on the second?

Probably the old classic "When Worlds Collide", but it was a long time since
I last saw it.

Itsn't there a year 2028 bug in UNIX, like the year 2000 bug in DOS. What
did they know...

Daniel

=====================================================================

Nortel Ltd, E-Mail : celano@
140 greenway,
Harlow Business Park, TEL : (01279) 405316
Harlow,
Essex.
CM19 5QD FAX : (01279) 405070

=====================================================================

Run for the hills...

Posted by Nick Waterman on 1998/03/12 13:41

Daniel Celano said:

Itsn't there a year 2028 bug in UNIX, like the year 2000 bug in DOS. What
did they know...

2038, not 2028

3:14 am, Tuesday 19th Jan 2038, in fact.

Hmm... so just as I'm reaching retirement age, they'll be DESPERATE to
employ old UNIX gurus to fix their ancient UNIX software, in the same
way that these days, COBOL programmers can earn a packet over the y2k
thing.

That's assuming that UNIX is still using 32-bit signed integers for
time_t by then. It would actually be remarkably easy to upgrade it to
64 bits or so - far easier than the "2-digit year" 2000 saga. Programs
would need recompiling, but not re-writing.

It's also assuming we're not made extinct 10 years earlier :-)

Nick Waterman. Network Consultant / Sysadmin - LEOnet
Beating tomorrow's technology into submission.
nick-sig@ Team *AMIGA*!
IBM: Ill'manners Being Mandatory

Run for the hills...

Posted by David C. on 1998/03/12 14:31

Previously, Nick Waterman wrote of the end of UNIX's world being at...

3:14 am, Tuesday 19th Jan 2038, in fact.

That's assuming that UNIX is still using 32-bit signed integers for
time_t by then. It would actually be remarkably easy to upgrade it to
64 bits or so - far easier than the "2-digit year" 2000 saga. Programs
would need recompiling, but not re-writing.

For the uninitiated, I presume he means UNIX use a 32-bit signed integer
(a number that can go from -1073741824 to +1073741823, or something
along those lines) to show the number of seconds since a certain point
in time. My Psion uses the same technique for seconds since the start
of 1970 to tell the time. Thus, when the seconds run out, the computer
gets all confused...

Why bother upgrading it, though? Why not just give it a new starting
point and go from 0 again?

Incidentally, numerous other time-keeping devices (from digital watches
to video timers) use 2-digit years, but they wrap around again at a
certain point (something like 2080 for my current Databank watch).
Well, they were created to work for rather less than a human lifetime
before being superceded, I imagine...

It's also assuming we're not made extinct 10 years earlier :-)

Even if we aren't, we'll be too busy struggling to survive to be
concerned about UNIX's profits...!

Dave Chilard

Run for the hills...

Posted by Martin G. on 1998/03/12 14:35

On Thu, 12 Mar 1998, Chilard D wrote:

Previously, Nick Waterman wrote of the end of UNIX's world being at...

3:14 am, Tuesday 19th Jan 2038, in fact.

That's assuming that UNIX is still using 32-bit signed integers for
time_t by then. It would actually be remarkably easy to upgrade it to
64 bits or so - far easier than the "2-digit year" 2000 saga. Programs
would need recompiling, but not re-writing.

For the uninitiated, I presume he means UNIX use a 32-bit signed integer
(a number that can go from -1073741824 to +1073741823, or something
along those lines) to show the number of seconds since a certain point
in time. My Psion uses the same technique for seconds since the start
of 1970 to tell the time. Thus, when the seconds run out, the computer
gets all confused...

Exactly, although I seem to recall calculating it to be the middle of 2106
because I think the time fields are stored as 32bit unsigned integers.

I'm sure they will have released an upgrade by *then*.

Maritn

UNIX clocks

Posted by Nick Waterman on 1998/03/12 14:57

Martin Greenaway said:

3:14 am, Tuesday 19th Jan 2038, in fact.

That's assuming that UNIX is still using 32-bit signed integers for
time_t by then. It would actually be remarkably easy to upgrade it to
64 bits or so - far easier than the "2-digit year" 2000 saga. Programs
would need recompiling, but not re-writing.

For the uninitiated, I presume he means UNIX use a 32-bit signed integer
(a number that can go from -1073741824 to +1073741823, or something

Exactly, although I seem to recall calculating it to be the middle of 2106
because I think the time fields are stored as 32bit unsigned integers.

# grep time_t /usr/include/time.h
typedef long time_t;

That's "long", not "unsigned long".

I'm sure they will have released an upgrade by *then*.

Indeed....

And it's much easier to upgrade to 64-bit LONGs than it is to change
your "epoch", by the way. Both involve recompiling your code, but
changing the epoch also involves re-writing any code that has made
rash assumptions about the epoch being jan 1st 1970 (or whatever), or
when leap-years occur, and stuff. There are PROBABLY far fewer
programs that'll break if your LONGs suddenly get LONGER.

Anyway, this has drifted almost (but not quite) as far off-topic as
the disney thread.

Nick Waterman. Network Consultant / Sysadmin - LEOnet
Beating tomorrow's technology into submission.
nick-sig@ Team *AMIGA*!
God is not dead! He's alive and autographing bibles at Cody's

Run for the hills...

Posted by Ben Dunkley on 1998/03/12 17:18

On Thu, 12 Mar 1998, Chilard D wrote:

Previously, Nick Waterman wrote of the end of UNIX's world being at...

3:14 am, Tuesday 19th Jan 2038, in fact.

That's assuming that UNIX is still using 32-bit signed integers for
time_t by then. It would actually be remarkably easy to upgrade it to
64 bits or so - far easier than the "2-digit year" 2000 saga. Programs
would need recompiling, but not re-writing.

For the uninitiated, I presume he means UNIX use a 32-bit signed integer
(a number that can go from -1073741824 to +1073741823, or something
along those lines) to show the number of seconds since a certain point
in time. My Psion uses the same technique for seconds since the start
of 1970 to tell the time. Thus, when the seconds run out, the computer
gets all confused...

Why bother upgrading it, though? Why not just give it a new starting
point and go from 0 again?

Because most time based calculations (like when a payment is due) will use
the value in seconds. This is less confusing than working it out from
dates and times and years... And the value is available. So if you change
the starting point, the whole set of data in the database gets screwed.

Same problem for the milennium bug - We could let it just wrap around, but
then everyone's bank cards would be expired by about 1001 years. Give or
take.

Ben.

*------------------------------------------------------*
| Tomorrow never comes. That's because she's going out |
| with A Week on Thursday. He always comes too soon. |
*------------------------------------------------------*

O _____________
/ \ /3
o / X BAD \ / 3
< Fish X 3
. \__ TRIP / \ 3
/____________/ \3

Run for the hills...

Posted by Ben Dunkley on 1998/03/12 17:29

On Thu, 12 Mar 1998, Pringlespanion wrote:

Same problem for the milennium bug - We could let it just wrap around, but
then everyone's bank cards would be expired by about 1001 years. Give or
take.

Oops, 101 years. (last two digits. D'oh!)

Ben.

*------------------------------------------------------*
| Tomorrow never comes. That's because she's going out |
| with A Week on Thursday. He always comes too soon. |
*------------------------------------------------------*

O _____________
/ \ /3
o / X BAD \ / 3
< Fish X 3
. \__ TRIP / \ 3
/____________/ \3

*------------------------------------------------------*
| Tomorrow never comes. That's because she's going out |
| with A Week on Thursday. He always comes too soon. |
*------------------------------------------------------*

O _____________
/ \ /3
o / X BAD \ / 3
< Fish X 3
. \__ TRIP / \ 3
/____________/ \3