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? ;-) -- 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 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? ;-)
We'll be too busy planning to escape the exploding sun to notice But if I'm still around, I promise to fix all your 64 bit code before the roll-over -- 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
Anders Johansson wrote:
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? ;-)
We'll be too busy planning to escape the exploding sun to notice
But if I'm still around, I promise to fix all your 64 bit code before the roll-over
I guess I'd better start saving for a 128 bit CPU. ;-) -- 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 8:10 am, Anders Johansson wrote:
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 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 <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 -- 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 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). -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
-- 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
[ 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
participants (4)
-
Anders Johansson -
Bryan J. Smith -
James Knott -
Jerry Feldman