Implementing time_t as 64 bit to solve Y2038 problem.

[Arie_tondo]

Hi,

We use SDK nRF5_sdk15.2 and ARM GCC cross compiler to develop application that runs on nRF52840.

We use new lib, as it was done in examples.

I noted recently that time_t is implemented as signed 32 bit what means that it can cause problem in 2038.

We use time_t to save epoch as we need to use c library functions (like mktime, ...)

Is there a way to change the definition of time_t to 64 bit or otherwise prevent the Y38 problem? 

[AHaug]

Hi,

Depending on what IDE and SDK you are using, time_t is implemented as different things. In Keil with nRF5 SDK time_t is implemented as an unsigned 32 bit int which will most likely be hit by the Y38 issue. As far as I can see typecasting this to a 64bit based type may cause code-compliancy issues with other functionalties depending on the time library. Since the nRF5 SDK is in maintenance mode, there are no guarantees that this will be fixed - for more details see this blog post.

One option to avoid this issue is move from nRF5 SDK to nRF Connect SDK (NCS) and Visual Studio Code, where time_t is implemented as the 64 bit type long long.

I've posted two images below from testing and verifying time_t type in NCS v1.9.1. 

Type declaration of time_t in time.h:

 

Output of example printing type declaration:

Let me know if this answers your question, and if you need any pointers to how to get started with NCS

Kind regards,
Andreas