This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Year 2038 problem
- From: Steven Abner <pheonix at zoomtown dot com>
- To: newlib at sourceware dot org
- Date: Mon, 12 Sep 2011 11:22:16 -0400
- Subject: Re: Year 2038 problem
- Authentication-results: ecout2 smtp.mail=pheonix@zoomtown.com; spf=unknown
- Authentication-results: ecout2 smtp.user=pheonix@zoomtown.com; auth=pass (LOGIN)
- References: <4E6DDAFF.8080307@embedded-brains.de>
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