I have not written a technical blog post in a long time. Yesterday I learned about the Year 2038 Problem and I wrote some code to demonstrate the problem. The Year 2038 Problem involves Unix time which is the number of seconds since January 1, 1970 stored as a signed 32-bit integer. The problem is that a signed 32-bit integer has a maximum value of 2147483647 and that value will be exceeded on January 19, 2038. So in just 18 years software that is trying to use Unix time will get an unexpected value.
The easiest way to see this problem is to write a MySQL query which attempts to get the Unix timestamp for a date after January 19, 2038. The following query will return the value 0 which is clearly incorrect and unexpected:
SELECT UNIX_TIMESTAMP('2038-01-20 00:00:00') AS Epoch;
On a 32 bit operating system like Windows XP you can see the problem by compiling a small C program which attempts to get seconds since the epoch for a date after January 19, 2038.
#include <stdio.h>
#include <time.h>
int main(void) {
struct tm t;
time_t t_of_day;
t.tm_year = 2038 - 1900; // Year - 1900
t.tm_mon = 0; // Month, where 0 = January, 7 = August
t.tm_mday = 20; // Day of the month
t.tm_hour = 0;
t.tm_min = 0;
t.tm_sec = 0;
t.tm_isdst = 1; // Is DST on? 1 = yes, 0 = no, -1 = unknown
t_of_day = mktime(&t);
printf("Seconds since the Epoch: %ld\n", (long) t_of_day);
}
This code will give you the unexpected value of -1. On a 64 bit operating system like Windows 10 you will get a reasonable value of 2147572800 since it is not using a signed 32-bit integer. This problem will mostly affect older computers running 32-bit operating systems, embedded systems running Linux, and MySQL. While you might think you have plenty of time before this becomes a problem, it is only necessary for software to attempt to get a date 20 years from now in the form of Unix time to encounter this problem.
