This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Year 2038 problem


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.

Hi;
 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 :) 

Steve


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]