Only 13 billion milliseconds from now...
by Jim Allen
April 13, 2001
I was coding a Date Sniffer
in javascript on April 13, 2001, when it suddenly dawned on me that
we are approaching an important milestone in computing history, and
also another possible source of Y2K-like problems for our beloved computers.
The javascript utility I was creating, a Date Sniffer, is a script that
examines your browser's own Date object, and prints out the values of all
the properties it can find there. You can see an example of a
complete Date Object Sniffer at Javascript Workbench.
I had written this code in an html file's body:
<script language="JavaScript"><!--
var yourDate = new Date();
document.write("yourDate.getTime() = " + yourDate.getTime());
document.close();
//-->
</script>
which, when I browsed it just after midnight on April 13, 2001, yielded:
yourDate.getTime() = 987139244810
Now, like any odometer-watching American automobile driver, I took one look
at this number and without any calculating, said to myself, "Hey, this baby's
gonna roll over soon!" I caught hold of my enthusiasm when I counted up the
digits and realized we were talking about billions and billions and billions,
as Carl Sagan used to say. Big numbers can be deceptive.
The .getTime() function is a function built into Javascript. When you have assigned
the Date object to a variable (var yourDate = new Date();), you can get a number of
values. For example, the number of the month is retrieved with .getMonth(); and the
current minute with .getMinute(). When you use .getTime(), Javascript returns the number of
milliseconds that have passed since midnight, January 1, 1970, in Greenwich, England;
at least according to your computer's internal clock.
In Javascript, 00:00:00 GMT on 01-01-1970 is a magical date called "the epoch"
according to Arman Danesh. [1] No Date object may be created in Javascript before
this date. This is the absolute beginning of time, the zero hour,
on which all the time calculations in javascript
are based. This integer value is counted in milliseconds, which you can access
with .getTime().
So to continue the story, I mentally inserted my commas and counted up the places,
and realized I was staring at 987,139,244,810 or in American units, nine hundred
eighty-seven billion, one hundred thirty-nine million, two hundred forty-four thousand,
eight hundred and ten milliseconds. I started to put the number into my pocket
calculator, but the big number's twelve digits were far too many to fit on my cheap calculator's screen.
What to do?
I realized I could lop off three decimal places by considering seconds rather than
milliseconds. Sliding the decimal point three places to the left (1 millisecond = .001 second)
gave me 987,139,244 point 810 seconds, a much more manageable figure… almost.
These nine digits were still one too many for my eight-digit pocket calculator!
Doing a quick subtraction on scratch paper (a pre-calculator math aid),
I saw that 12,860,756 seconds were
needed to roll over the chronometer, and now I had a number I could fit in my calculator.
The rest was easy: 12,860,756 seconds / 60 gives 214345.93 minutes, which / 60 gives
3572.4 hours, which / 24 is surprisingly, only 148.8 days away! In 148 days,
this integer representation of time in all browsers will lengthen by another digit.
It will soon be trillions of milliseconds since the dawn of the epoch!
I checked a calendar and discovered the magic date: September 8, 2001.
I was worried that this may be expressed in GMT,
so I confirmed the date by the following script:
<script language="JavaScript"><!--
var yrDate = new Date();
//Note the trillionth millisecond
yrDate.setTime(1000000000000)
document. write(yrDate.toLocaleString() + " EST" + "<br><br>);
document. write(yrDate.toGMTString()");
document.close();
//-->
</script>
which when browsed reports:
09/08/2001 21:46:40 EST
Sun, 9 Sep 2001 01:46:40 UTC
So, will this magic date of Sept. 8, 2001 be a time for script geeks worldwide to
celebrate the Trillionth Millisecond? Or will there be Y2K-like problems
generated by the new extra digit? The extra digit occurs only
in the base-ten representation of this number, so nothing on the level of
binary should be effected. But any machine that represents time in milliseconds
and uses this same epoch-date will suffer increased risk at one trillion.
Some software may allot only twelve digits to the result of a
.getTime() function,
and those programs will experience a new bug, er, feature. But otherwise, I see
nothing to fear.
I still don't know whether the javascript millisecond clock is effected by one's
system clock settings (including any incorrect settings) [2],
and also whether everyone everywhere will change at once,
or will the change happen successively by time zones, as the world turns?
Write to me with your ideas.
The javascript codeheads need to get the word out, and prepare for the big event:
watching the javascript .getTime() function
roll over into the Trillionth Millisecond. Wahoo!! Party!!
Jim Allen
Article Footnotes:
[1] Arman Danesh says 01/01/1970 at 00:00:00 GMT is called "the epoch" in
Arman Danesh, Teach Yourself Javascript 1.1 in a Week, 2nd edition, 1996,
Sams.net, p. 111.
[2] Added April 15:
I have tested this now by
setting my pc's system clock to the year 2002. The Epoch Chronometer reads 1,018,851,724,981 and
the Countdown says negative 18851737 to go, so evidently:
- the javascript millisecond clock is tied to the
system clock (on the pc at least), and
- both my browser and my operating system make it through to the other side
of the trillionth millisecond. (I'm still on W95!)
|
|
