Time
Monday, January 1st, 2007Time is passing. The Time is coming. Which time? Well, at this time ; ) the one I’d like to discuss is when Unix Time overflows at 2038-01-19T03:14:08. The current solutions most people have proposed have involved recompiling anything necessary using either an unsigned time_t (giving another 70 years) or using a 64 bit value (giving another 292+ billion years) to delay the problem for a while.
These are fairly workable solutions, for a definition of workable that includes “somewhat quick and dirty”. Using usigned just puts off the problem a while, and I think going to 64 bits is both wasteful and stingy at the same time. Bothering to keep space for more than a million years, at the current rate of software change, is just a waste of time. : ) Additionally, NOT bothering to consistently track milliseconds (which can be very important for computing purposes) is just poor design based on too much emphasis on backwards compatibility. Normally I’m all over backwards compatibility, but I think enough things would still be broken by the improvement, that it might just be better to get fresh.
As cpu speeds continue to go up, someday we will exceed milliseconds, and have multiple log entries with the same timestamp.
What about the past? With a properly designed system, we could do a better job of dealing with history. Right now, when people want to specify a time in the past, they can only use binary timestamps for events going back to 1901. Anything earlier must be represented in another format, making direct comparisons impossible.
I am sure there are a number of historical applications that could benefit from a consistent, universal, linear time standard. One that comes to mind is digital photo collections that include scanned items; My personal collection does not currently go back before 1901, but it comes close, and I’m sure that others’ do.
Let’s replace that silly little 32 bit number with a 256 bit number!!! With 256 bits, we can measure the entire length of estimated creation in the smallest possible unit of time, Planck Time. Plank time is 5.4×10^-44 seconds, the big bang is estimated at 13.7×10^9 years ago, and a year is 3.2×10^7 seconds, for a total of about 8×10^61, which would take a little over 200 bits to represent. Add only one more bit, and you can go 13.7 billion years into the future too. Spice it up to 256 bits to keep the word-alignment folks happy, and you’ve got the universe in your pocket.
Admitedly, we only have an estimate of Plank time, but anything that we use is going to need periodic correction for drift anyway… computers use some of the cheapest timepieces in creation… It would be nice to have a processor that could add only one in its time register, but as a matter of practicality (and probably special relativity too) until things get INSANELY fast, I think we’re going to be adding something like 5×10^34 or more each clock cycle.
Unfortunately a grand proposal like this will be destroyed by one of two things:
- THAT’S TOO MANY BYTES!
- Cope. it’s not that bad. Disk is cheap.
- WHERE SHOULD WE PUT ZERO?
- 14.7 billion years ago? 13.7 billion years ago? The “year” 0? 3BC? 30AD? 1901? 1970? 2000? 2001? I really don’t care too much, so long as no one tries to divide by it. (they will.)
I should mention though, that 13.7 billion years ago is probably a pretty hard time to pin down exactly, and someone is eventually likely to play with the date routines and find out something silly, like “The universe began on a thursday.”
Additional info: http://en.wikipedia.org/wiki/Planck_time