When writing a pretty & small countdown script for New Year’s Eve I mentioned that we’ll be in trouble at January 19^th in the year 2038. While handling with unix-timestamps (seconds since 1/1/1970) I figgured out that the signed 32-big-integer that is used in for time_t is not big enought to hold 2147472000.

Most operating systems for 64-bit architectures already use 64-bit integers in their time_t but this doesn’t solve the problem at all because it may happen that a program regards a 64-bit timestamp from the OS as a 32-bit value. The consecution would be that just the lower 32 bits would be read. On 1/19/2038 this would cause a backshift into the year 1901. (The lower 32bits of 1/19/2038 are -2³¹ = December 13^th in 1901)

The move to 64-bit architecture is already underway and probably will be completed before 2038 but what about the embedded 32-bit based systems? Will it really be necessary to re-compile some software to make them work with a (signed) 64-bit timestamp?

What about all the databases e.g. of banks or insurance companies which are full with timestamps? Lots of questions - I’m excited…