Report
3 years, 4 months ago.

Year 2038 Bug: rtc_time.h and time.h, 32bit signed

I have been using mbed functions to set and read the RTC using the rtc_time.h interface. This seems to suffer from the year 2038 bug that results from using a 32bit signed int for time_t to count seconds. Max value of a 32bit signed int is 2,147,483,647. And I have confirmed that if I use set_time(2,147,483,647) the date is correctly set to Jan 19, 2038. But if I do set_time(2,147,483,648) the clock is not updated. The problem seems to be with definition of time_t inside time.h.

Sanity check, can someone confirm this is the case? The year 2038 is actually not that far away. It would be unacceptable then to use these functions in a real product. Is there any chance of getting the mbed libraries updated to fix this bug? Does anyone have a workaround?

Comment on this question

1 Answer

3 years, 4 months ago.

in time.h

"typedef unsigned int time_t; /* date/time in unix secs past 1-Jan-70 */"

The Literal number you are using is signed

try

2,147,483,648u

The compiler will take the literal number as an unsigned integer

Yup, that was it, thanks. Follow up question then is, where does one find time.h that is being used in the online mbed compiler?

posted by Graham S. 04 Apr 2016

The online compiler uses ARMCC as its core. time.h and stdio.h etc are 'C standard libraries' which are used by this compiler. If you use an 'offline' compiler such as Keil (also using ARMCC) and the mbed-src (or mbed-dev) you will see time.h as part of the project structure if you 'include <time.h>' as a header file. Hope this helps.

posted by Martin Simpson 04 Apr 2016

That only delays the problem for less than 70 years. What do we do when our mbed code crashes in 2106? ;-)

posted by Andy A 05 Apr 2016