Seasoned STM32 programmers may remember the Y2k frenzy around year 2000, when some older programs which assumed they will never operate beyond the 20th century and e.g. used 2-digit BCD coding for calendar year, were in risk of failing. While such programs were comparatively rare, it was not easy to tell without closer inspection, whether a program was "safe" in this regard or not.

A similar boundary is slowly approaching, as the UNIX epoch (seconds since 1.Jan 1970) will reach 2^31 on 19.Jan 2038, overflowing in systems which maintain time in 32-bit (signed) int. This epoch is used for keeping date in many systems using the standard C functions, including compiler suites for STM32 based on gcc, which usually employs some variant of the newlib standard C library. So, is this setup vulnerable to the Y2k38 problem?

Checking sizeof(time_t) on most not-that-old installations of such system may reveal, that time_t type which holds the UNIX-epoch time, is declared as 64-bit integer, so it should be completely safe for many centuries to come. However, the nature of problem is not that simple, and it turned out, that one particular function, mktime(), used to convert calendar-style date/time to UNIX-epoch based time, still suffered from the Y2k38 problem, due to the C-language implicit type conversions.

This latter problem was already fixed, too; so users of newest versions of gcc/newlib should be safe.