The Great UNIX TIME Clock
Bernie Cosell
} A discussion came up in one of my classes about the UNIX time clock and
} when it runs out. There seems to be some confusion on when it will run
} out, and what the consequences might be. Can anyone shed some lite on
} this topic?
Well, one way to approach the problem would be the simple, brute
force one: go in and manually set the date to the largest positive
number minus a bit, then see what date the system thinks it is, and
then wait for that to turn over and become negative [to check
whether anything depends on the _sign_ of the time]. Then do the
same with the largest unsigned and see what happens. Then you can
tell us...
/Bernie\
--
Bernie Cosell ber...@fantasyfarm.com
Fantasy Farm Fibers, Pearisburg, VA (703) 921-2358
--->>> Too many people; too few sheep <<<---
Taki Kogoma
<34vof5$e...@nyx10.cs.du.edu> in alt.folklore.computers:
>[Regarding the possible problems when the standard Unix clock
overflows in 2038]
>
>What happens when it wraps around? Good question. We have several years to
>head off the problem, and hopefully more foresight than the folks who
>designed the mess of COBOL programs with 2-digit year values.
There is a school of thought which asserts that by 2020 or so, 64-bit
machines will be the standard. With constantly growing hardware and
OS modifictaions, the rollover problem will be postponed by increasing
sizes of unsigned long until Sol goes nova.
I'm not sure if I completely buy this theory, tho...
--
Capt. Gym Z. Quirk | "I'll get a life when someone
(Known to some as Taki Kogoma) | demonstrates that it would be
qu...@unm.edu | superior to what I have now."
Veteran of the '91 sf-lovers re-org. | -- Gym Quirk
Tony Bailey
when it runs out. There seems to be some confusion on when it will run
out, and what the consequences might be. Can anyone shed some lite on
this topic?
--
Tony Bailey mo...@cs1.bradley.edu
Bradley University
--
Jim M. Pierce
[] years to head off the problem, and hopefully more foresight than the
[] values.
Its because it would require using another column on the punch cards
when the programs were originally written and those columns were
precious ! I never used punch cards, but thats why it happened that way,
not because of lack of foresight.
--
Jim Pierce B.Sc. Disclaimer:Standard.
'Punk Flamingos spray their feathers brown...'
Jay Maynard
Tony Bailey <mo...@cs1.bradley.edu> wrote:
>A discussion came up in one of my classes about the UNIX time clock and
>when it runs out. There seems to be some confusion on when it will run
>out, and what the consequences might be. Can anyone shed some lite on
>this topic?
The standard Unix clock is a 32-bit signed integer, at one count per second
from 0000 GMT, 1 January 1970. 2^31-1 seconds from that date turns out to be
18 January 2038, 03:14:07 GMT. (This may be a few seconds off; it was
computed at exactly 365.25 days per year, which ignores leap seconds but is
otherwise accurate for the time frame in question.) (BTW, for those of you
that play IRC Jeopardy, their answer to this question is wrong - and that cost
me 13,200 points once. They think it's 2034.)
What happens when it wraps around? Good question. We have several years to
head off the problem, and hopefully more foresight than the folks who
designed the mess of COBOL programs with 2-digit year values.
--
Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can
jmay...@admin5.hsc.uth.tmc.edu | adequately be explained by stupidity.
The US Constitution: 1789-1994. RIP.
Lennart Regebro
>There is a school of thought which asserts that by 2020 or so, 64-bit
>machines will be the standard. With constantly growing hardware and
>OS modifictaions, the rollover problem will be postponed by increasing
>sizes of unsigned long until Sol goes nova.
Well, with one second intervals, a 32-bit clock does 49710.26962963 days.
That's about 136 years.
A 64-bit clock, would then span 584542046090 years (with a year that's
265.25 days long).
So in the year 584,542,047,990 it would be time for the 64-bit rollover.
I would hope that we during these 584 billion years either have fixed
this problem, or started with 128-bit computers. Which would mean that
we don't hav to fix it in until the year
10,782,897,524,560,000,000,000,000,000,000 AD.
I sincerely doubt that ANY of the original unix code is left by then,
and we can probably count on us having gotten a new time zero pointer.
--
Lennart Regebro Lennart...@scs.no (Try this first)
Galactic Guide Field Researcher reg...@stacken.kth.se (Spare address)
Hans Mulder
>In article <34vl7u$f...@cs1.bradley.edu>, Tony Bailey writes:
>} A discussion came up in one of my classes about the UNIX time clock and
>} when it runs out. There seems to be some confusion on when it will run
>} out, and what the consequences might be. Can anyone shed some lite on
>} this topic?
>Well, one way to approach the problem would be the simple, brute
>force one: go in and manually set the date to the largest positive
>number minus a bit, then see what date the system thinks it is, and
>then wait for that to turn over and become negative [to check
>whether anything depends on the _sign_ of the time]. Then do the
>same with the largest unsigned and see what happens. Then you can
>tell us...
Time() is documented to return -1 when it cannot determine the correct time
(that's why it needs to be signed). On may platforms, the largest unsigned
happens to turn into -1 when interpreted as a signed quantity. Of course
all applications religiously check for error returns :-), so they'll all fail
if time() returns the largest unsigned.
One idea would be to change the documentation of time() into "returns an
unsigned long; -1UL means error, all other values are seconds since 1 Jan 1970
midnight GMT". That would be binary compatible with the current situation,
and delays the need to change to 64-bit longs until the year 2106.
--
HansM
Craig Dickson
|Well, with one second intervals, a 32-bit clock does 49710.26962963 days.
|That's about 136 years.
|A 64-bit clock, would then span 584542046090 years (with a year that's
|265.25 days long).
|
|So in the year 584,542,047,990 it would be time for the 64-bit rollover.
|I would hope that we during these 584 billion years either have fixed
|this problem, or started with 128-bit computers. Which would mean that
|we don't hav to fix it in until the year
|10,782,897,524,560,000,000,000,000,000,000 AD.
|I sincerely doubt that ANY of the original unix code is left by then,
|and we can probably count on us having gotten a new time zero pointer.
Or at least a new calendar system.
--
Craig Dickson <c...@netcom.com>
"Inscrutable people tend to drink inscrutable beer." - Elizabeth of Windsor
World Wide Web alt.usenet.kooks archives: ftp://ftp.netcom.com/pub/crd/auk.html
To receive the a.u.k FAQ, send me email with Subject: send alt.usenet.kooks faq
Charlie Brett
: Well, one way to approach the problem would be the simple, brute
: force one: go in and manually set the date to the largest positive
: number minus a bit, then see what date the system thinks it is, and
: then wait for that to turn over and become negative [to check
: whether anything depends on the _sign_ of the time]. Then do the
: same with the largest unsigned and see what happens. Then you can
: tell us...
I saw this and could resist, so I tried it (on a test system, not mine :-)
This is what I got:
:
:
Mon Jan 18 20:14:07 MST 2038
Mon Jan 18 20:14:07 MST 2038
Mon Jan 18 20:14:07 MST 2038
Fri Dec 13 13:45:52 MST 1901
Fri Dec 13 13:45:52 MST 1901
Fri Dec 13 13:45:52 MST 1901
:
:
Then I got a SCSI system panic (I guess the SCSI driver wasn't crazy
about the wrap around).
For those of you that wish to live dangerously, the program was:
#include <limits.h> /* has INT_MAX defined to 2147483647 */
#include <time.h>
main()
{
time_t val = INT_MAX;
system("/usr/bin/date"); /* get the current date */
stime(&val);
while (1) {
system("/usr/bin/date"); /* now what is it? */
}
}
Charlie Brett - HP Ft. Collins
My opinions are my own and in now way represent Hewlett Packard.
Charlie Gibbs
(Jim M. Pierce) writes:
>Jay Maynard wrote:
>[] years to head off the problem, and hopefully more foresight than the
>[] folks who designed the mess of COBOL programs with 2-digit year
>[] values.
>
> Its because it would require using another column on the punch cards
>when the programs were originally written and those columns were
>precious ! I never used punch cards, but thats why it happened that way,
>not because of lack of foresight.
It was even worse in the first place I worked. To save card
columns, only the last digit of the year was stored. Many of
my first assignments (this was 1970) were to change programs
to insert a '7' instead of a '6' when printing the year on
reports.
Charli...@mindlink.bc.ca
"It's lonely here, there's no one left to torture." -- Leonard Cohen
Steven King [Really!]
>So in the year 584,542,047,990 it would be time for the 64-bit rollover.
>I would hope that we during these 584 billion years either have fixed
>this problem, or started with 128-bit computers. Which would mean that
>we don't hav to fix it in until the year
>10,782,897,524,560,000,000,000,000,000,000 AD.
>I sincerely doubt that ANY of the original unix code is left by then,
>and we can probably count on us having gotten a new time zero pointer.
You care to wager on that? Some systems are like the Roach Motel.
Programs check in, but they don't check out. They just get "maintained"
for ever and ever and ever...
So, I'll see you in 2^128 seconds. The bet is a penny with 5% annual
compounded interest. No fair rounding until it comes time to pay up! :-)
--
----------------------------------------<Steven King, ve...@pshrink.chi.il.us>--
Welcome to alt.folklore.computers, where subject drift is a highly refined
art form.