Comments on: The Year 2038 Bug! Recompile before it’s too late! http://www.zerohex.org/2005/12/28/the-year-2038-bug-recompile-before-its-too-late/ ØxØØØ ...because I blog what I want! Tue, 06 Jan 2009 07:53:22 +0000 http://wordpress.org/?v=2.0.1 by: Joe http://www.zerohex.org/2005/12/28/the-year-2038-bug-recompile-before-its-too-late/#comment-144 Sun, 19 Feb 2006 22:10:07 +0000 http://www.zerohex.org/2005/12/28/the-year-2038-bug-recompile-before-its-too-late/#comment-144 Well, beter that we know now then in 2037. :-) Well, beter that we know now then in 2037. :-)

]]> by: Bobo http://www.zerohex.org/2005/12/28/the-year-2038-bug-recompile-before-its-too-late/#comment-141 Thu, 16 Feb 2006 10:08:11 +0000 http://www.zerohex.org/2005/12/28/the-year-2038-bug-recompile-before-its-too-late/#comment-141 True that it wont concern most people, but people who use online calendars etc... will want stuff to work after 2038 on the calendar. I have programmed a maintenance calendar into our company's app and large construction companies use it to plan maintenance and job times etc.. Some of them even run it to after 2038 (when the calendar breaks down). So a workaround is needed. Its an online calendar programmed in php btw True that it wont concern most people, but people who use online calendars etc… will want stuff to work after 2038 on the calendar. I have programmed a maintenance calendar into our company’s app and large construction companies use it to plan maintenance and job times etc.. Some of them even run it to after 2038 (when the calendar breaks down). So a workaround is needed. Its an online calendar programmed in php btw

]]> by: Marios Tziortzis http://www.zerohex.org/2005/12/28/the-year-2038-bug-recompile-before-its-too-late/#comment-114 Sun, 22 Jan 2006 21:05:18 +0000 http://www.zerohex.org/2005/12/28/the-year-2038-bug-recompile-before-its-too-late/#comment-114 Yeah Garett I agree on that, but you know.. Every now and then something new must come up just for the publicity! It is though a potential risk that must be taken into consideration since similar bugs might appear soon. Yeah Garett I agree on that, but you know.. Every now and then something new must come up just for the publicity! It is though a potential risk that must be taken into consideration since similar bugs might appear soon.

]]> by: Garett Harnish http://www.zerohex.org/2005/12/28/the-year-2038-bug-recompile-before-its-too-late/#comment-110 Wed, 18 Jan 2006 21:49:04 +0000 http://www.zerohex.org/2005/12/28/the-year-2038-bug-recompile-before-its-too-late/#comment-110 If I understand correctly, the bug only affects 32-bit computers ... 64-bit processors are already out and they're thus good forl 9,223,372,036,854,775,807 seconds, which means 64 bit computers are fine until Jan 25th 293,274,702,979 at 2:30:07pm GMT. That is far enough in the future not to concern ones self with. And while I've been surpised how slow 64-bit processors are being adopted today, they will have come and gone by 2038. If I understand correctly, the bug only affects 32-bit computers … 64-bit processors are already out and they’re thus good forl 9,223,372,036,854,775,807 seconds, which means 64 bit computers are fine until Jan 25th 293,274,702,979 at 2:30:07pm GMT. That is far enough in the future not to concern ones self with. And while I’ve been surpised how slow 64-bit processors are being adopted today, they will have come and gone by 2038.

]]> by: Socratis http://www.zerohex.org/2005/12/28/the-year-2038-bug-recompile-before-its-too-late/#comment-102 Fri, 30 Dec 2005 16:48:33 +0000 http://www.zerohex.org/2005/12/28/the-year-2038-bug-recompile-before-its-too-late/#comment-102 HEhe nice post I highly doubt it that c or c++ or even z++ will be around until then. I think it is safe to say that armagedon will not be on 19th Jan 2038 ;) /S HEhe nice post I highly doubt it that c or c++ or even z++ will be around until then. I think it is safe to say that armagedon will not be on 19th Jan 2038 ;)

/S

]]>