On Thursday 01 June 2006 13:50, James Knott wrote:
With 32 bit CPUs, the clock is supposed to roll over to 0, in the not too distant future.
Some time in early 2038, I believe
Has this issue been resolved in the 64 bit version of Linux?
No, it's just been postponed a few billion years
What will we do when 64 bit clocks roll over to 0? ;-) Actually, it does not roll over to 0. The time_t type is defined as a 32-bit signed integer on 32-bit systems that becomes negative somewhere around June, 2038. This was a problem for the financial industry that routinely
On Thursday 01 June 2006 8:10 am, Anders Johansson wrote:
projects 50 years or more into the future. As Anders mentions time in
64-bit systems is not 64-bit (time_t and suseconds_t for struct timeval).
There was a big fight when the Unix 98 spec was being worked on, where many
wanted time_t to go to 64-bits on even 32-bit systems, and they would
define a "flag day" for the cutoff. At the time, I was working on what is
now Tru64 Unix. We had implemented full 64-bit time, but the existing
standards mangated that time_t be 32-bit.
This is a real problem for a lot of legacy applications where programmers
routinely used 'int' for time rather than time_t. I just got through
changing about 30 C++ modules because of this.
--
Jerry Feldman