The rationale given for why it hadn't been upgraded with all the other systems was that there was a short term advantage in cost savings, and by the time the problem surfaced, the executives who made the decisions would be long gone. Sure, it's a Dilbertism, but in the wake of the corporate scandals of 2001, doesn't it ring true?

Assuming that we'll all be on 64-bit (or 128-bit, or embryonic monkey-brain) processors at some point in the nebulous future is a mistake. Someone out there will decide not to upgrade. Some of my company's customers still use Windows 95. Last year I was at an airport, and the application displaying the arrivals and departures had crashed The terminal was showing a Windows 98 desktop.

Even if you decide that someone can fix it "later", possibly in the mad dash to fix legacy unix code in Fall of 2037, please document the issue.

-Logan
"What do I want? I'm an American. I want more."

What I don't really understand is why you could not make time_t an unsigned 4 byte int and thus get another 68 odd years out of it. Leaving aside the problems with C code that expects it to be signed. Why was it unsigned in the first place anyway?

As you say there are a lot of issues to be resolved. My main point was to abstract the time handling so at least that can of worms is all in the same place which will make it easier to deal with - all other things being equal.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

tachyon wrote, "What I don't really understand is why you could not make time_t an unsigned 4 byte int and thus get another 68 odd years out of it. Leaving aside the problems with C code that expects it to be signed. Why was it unsigned in the first place anyway?"

How would you denote my birthdate in 1967, if you use an unsigned forward-pointing integer measured from the epoch of 1970?

Java standardized on a 64-bit signed time in milliseconds from the same 1970 epoch, which gives them enough range to describe any moment from big bang to big whimper, remain coherent with code that thinks that 1970 was a pretty cool year, and still be a thousand times more precise than the standard unix time. I don't expect time() to follow that standard, but I do think it's safe to say, even considering the usual famous misquote, that 64 bits should be enough for anyone.

--
e d @ h a l l e y . c c

Well, in many areas a millisecond is long. It's a nice ping time to perlmonks.org, but I wouldn't like a millisecond main memory access time. For some physicists, even nanoseconds are not precise enough, they require pico-, femto- or even attoseconds. Unfortunally, with 64 bits and attosecond precision, you only have less than 18.5 seconds as your range.

Of course, you could always use XS, or Inline::C and use libtai http://cr.yp.to/libtai.html.

Abigail