[ I'll answer this on-list ] On Thu, 2006-06-01 at 07:50 -0400, James Knott wrote:

With 32 bit CPUs, the clock is supposed to roll over to 0, in the not too distant future. Has this issue been resolved in the 64 bit version of Linux? What will we do when 64 bit clocks roll over to 0? ;-)

32-bit POSIX, including 99.9% of the C code out there (_including_ Win32 on Windows**), uses absolute time off-set from January 1, 1970 00:00:00 using a 32-bit signed (31 positive bits). Mid-January 2038, this will overflow into -2 million or -1 (depending on the implementation). So either it will report the year as either 1901 or 1969 (and count backwards). True, 64-bit "clean" kernels, libraries and applications use a 64-bit POSIX time. **NOTE: Microsoft boasts how NT uses a 64-bit time in milliseconds and isn't affected by the 32-bit POSIX issue. 99.9% of Win32 code coming out of Visual Studio, even .NET, does have this issue -- because core Windows libraries (including core DLLs in Internet Explorer used by virtually _all_ programs since Visual Studio 5) are very much 32-bit POSIX, including the rollover issue. The issue is far more of a concern for embedded systems (which are 3-4 times more commonplace) than general desktops and servers. Especially since 32-bit microcontrollers will likely still be very commonplace and in wide-spread use in 2038. -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ------------------------------------------------------- Illegal Immigration = "Representation Without Taxation" -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com

On Thu, 2006-06-01 at 08:15 -0400, Bryan J. Smith wrote:

32-bit POSIX, including 99.9% of the C code out there (_including_ Win32 on Windows**), uses absolute time off-set from January 1, 1970 00:00:00 using a 32-bit signed (31 positive bits). Mid-January 2038, this will overflow into -2 million or -1 (depending on the implementation). So either it will report the year as either 1901 or 1969 (and count backwards).

Er, I meant -2 billion or -1. -- Bryan J. Smith Professional, technical annoyance mailto:b.j.smith@ieee.org http://thebs413.blogspot.com ------------------------------------------------------- Illegal Immigration = "Representation Without Taxation" -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com

On Thursday 01 June 2006 14:49, Jerry Feldman wrote:

As Anders mentions time in 64-bit systems is not 64-bit (time_t and suseconds_t for struct timeval).

Actually I didn't mention that, because I thought it was, at least in linux (I won't dispute your expertise on Tru64) A few greps through /usr/include seems to show that time_t is defined as long int in glibc (it's immediately defined as __time_t which is __TIME_T_TYPE which is __SLONGWORD_TYPE, and that is "long int") -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com

On Thursday 01 June 2006 16:57, Jerry Feldman wrote:

On Thursday 01 June 2006 8:59 am, Anders Johansson wrote:

...

On Thursday 01 June 2006 14:49, Jerry Feldman wrote:

...

As Anders mentions time in 64-bit systems is not 64-bit (time_t and suseconds_t for struct timeval).

Actually I didn't mention that, because I thought it was, at least in linux (I won't dispute your expertise on Tru64)

A few greps through /usr/include seems to show that time_t is defined as long int in glibc (it's immediately defined as __time_t which is __TIME_T_TYPE which is __SLONGWORD_TYPE, and that is "long int")

Which is 64-bits in an LP64 system (64-bit Linux and Unix systems).

Er, yes, that's what I said Did you perhaps have a "not" too many in your previous mail? -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com