This is down to what’s being called the “2038 bug”. It arises because Unix-based systems store the time as a signed 32-bit integer, in seconds, from midnight on January 1 1970. And the latest time that can be represented in that format, by the Posix standard, is 3.14am on January 19, 2038. (It’s a Tuesday. Better make sure your desk is clean on the Monday night.)
—Charles Arthur, “Oh no! The net has just 30 years to live!,” The Guardian (London), March 13, 2008
—Keith Hale, “Just when you thought it was safe . . . 2038,” Chicago Sun-Times, July 27, 1999
The problem stems from the common definition of the time_t as an integer containing the number of seconds since midnight, January 1, 1970. Most C/C++ runtime libraries define time_t as a long int. On most systems, long int is 32 bits, which means that we‘ve got a range of 2^31-1 (2,147,483,647) secondsuntil sometime on January 18, 2038. (Assuming Dr. GUI‘s Windows CE Palm-size PC has it right, that‘s a Monday. Figures.)
Since the number is signed, when the clock rolls over the time will be a very large negative number, giving us a time warp of a little over 136 years—we‘ll flip back to sometime late in December, 1901.
—Dr. GUI, “All Ready for 2000 and the Euro? What About 2038?,” MSDN Online Buzz, January 15, 2008
Y2K leap year bug