• A pure 'code fix' for the "2038 EpochAlypse" •
A product was developed (Gravimetric Air Sampler) using the AT32UC3C0512C MCU compiled using Atmel_Studio v6.2 and the AVR32/GNU C Compiler. This system schedules events and has to calculate time
differences. It all works great, but the realization came about that the product will cease to function properly on Jan 19th, 2038 at which 'time' the mktime function begins to calculate the date
as Dec 14th, 1901 and forward from there. This would probably not be too good for 'customer relations'...
When informing management that the fix would be a new MCU that can compile with a uint64_t for 'time_t' (or something along those lines) with re-written firmware, the room went silent with lots of cold stares... So, a solution was sought that DID NOT require a new MCU or re-writing loads of code (which is finally working correctly - for now at least).
It was discovered that the calendar for the year 2036 (2 years prior to the 'epochalypse') is a repeat of the calendar for the year 1980 (10 years past the Unix 'Epoch' of 1970). It was found that by determining if the dates needed to do mathematical calculations on occur after 2036, 56 years could be subtracted from the 'current' date, call mktime to get the seconds, call localtime to convert back to human decipherable time, add 56 back to the year and voila, the dates are correctly calculated all the way up to Jan 19th, 2094. This means that it's possible to get all the way through 2093 with no calculation errors.
The limitations are that you can calculate two dates that are both pre-2038 (calculate 'normally') or two dates that are both post-2037 (calculate using this 'method'). If one date is pre-2036 and the other is post-2038 then you're simply out of luck. This method works for the system it was developed for as it only needs to calculate the difference between dates that are a few months apart at most.
• Limitation of Liability: "In no event will Exact Circuit Design, LLC (or the owner) be liable for any loss or damage, including without limitation, indirect or consequential loss or damage, arising from the use of this information."
• USE AT YOUR OWN RISK •
When informing management that the fix would be a new MCU that can compile with a uint64_t for 'time_t' (or something along those lines) with re-written firmware, the room went silent with lots of cold stares... So, a solution was sought that DID NOT require a new MCU or re-writing loads of code (which is finally working correctly - for now at least).
It was discovered that the calendar for the year 2036 (2 years prior to the 'epochalypse') is a repeat of the calendar for the year 1980 (10 years past the Unix 'Epoch' of 1970). It was found that by determining if the dates needed to do mathematical calculations on occur after 2036, 56 years could be subtracted from the 'current' date, call mktime to get the seconds, call localtime to convert back to human decipherable time, add 56 back to the year and voila, the dates are correctly calculated all the way up to Jan 19th, 2094. This means that it's possible to get all the way through 2093 with no calculation errors.
The limitations are that you can calculate two dates that are both pre-2038 (calculate 'normally') or two dates that are both post-2037 (calculate using this 'method'). If one date is pre-2036 and the other is post-2038 then you're simply out of luck. This method works for the system it was developed for as it only needs to calculate the difference between dates that are a few months apart at most.
• Limitation of Liability: "In no event will Exact Circuit Design, LLC (or the owner) be liable for any loss or damage, including without limitation, indirect or consequential loss or damage, arising from the use of this information."
• USE AT YOUR OWN RISK •
Web Design by Exact Circuit Design, LLC - Copyright © 2010 All Rights reserved · E-Mail: info@exactcircuitdesign.com
Electronic Circuit Design, PCB Layout, Custom Firmware...