Year 2038 problem

Steven Abner
Tue Sep 13 16:29:00 GMT 2011

On Sep 12, 2011, at 6:12 AM, Sebastian Huber wrote:

> Since have a system that should operate for 30 years we have to address this problem somehow.

 Making it a long long is one solution. It is also not the only solution. A 32-bit time_t can be used for BC and AD years, with time_t -1 being a unique error return. I am currently trying to market (unemployed atm, and not a marketing wiz) such a time system and get accepted long before 2020. Apple rejected because I'm not a corporation, Others still waiting on, or still yet to contact. It could even be used with a variable timezone file system on embedded, for almost the same code size cost with an approximate 60% increase over a single timezone system (test was sequential years, and 5 out of 7 being easier than normal usage, assumption current time being normal usage). Oddly, it showed a 350MHz PPC almost as fast as an Intel Duo @ 2.26Ghz(Great news for cell phones and tablets). Have to redo that test yet. As redo and recheck other results.
  Just food for thought, for your debate, if I interpreted your intention correctly. And a plug for my code :) 


More information about the Newlib mailing list