Take some time to think about time
Y2K, archaic databases and spoOoOky integer overflows
At the moment of writing it is the 22nd of June, the day after summer solstice. The pessimist in me laments that the days will only get shorter from now on; the optimist knows that this also heralds the beginning of summer, meaning the best should be yet to come.
In the CS paradigm, time has often been a concept that proves more difficult to define than you might initially think. Some of you may have consciously experienced Y2K: because time was traditionally encoded in MMDDYY format, the whole (digital) world was going to go up in flames with the jump from '99 to '00.
There is a misconception that nothing was going to wrong in the end and systems were able to deal with this just fine, but this forgoes the fact that many software engineers at the time worked around the clock to mitigate the damage.
"What time is it?" "it's 1655891701"
Today, Unix-based systems run on Unix time, defined as the number of seconds since 00:00:00 UTC on January 1, 1970. This method, however, also has an Achilles' heel. The convention was to store this value as a signed 32-bit integer, which means that at 2³²-1 — or 03:14:07 UTC on January 19, 2038 — we are facing an integer overflow. The time will jump to -2³², better known as Friday the 13th (!) of December 1901. Systems that are particularly susceptible to this are, for example, SQL databases that store time as INT32.
The takeaway? If you're (still) in the data field at the end of the fourth decade of this century — and we're still using SQL databases instead of some blockchain or quantum-superpositioned and entangled qubits — take some time to check whether you have INT32 columns that contain time data. If so, simply converting them to INT64 should alleviate the issue for another 292 billion years, or 584 billion solstices.
