Unix or Epoch time turned 50 and Y2K38 problem is coming

By | December 10, 2020

The Unix time was born January First 1970 exactly at 12 AM with no minutes and seconds. Its age already exceeds 1 billion and 600 millions seconds or 0x5F5E1000 in hex value, so far it is good for 32-bit positive signed integer, but until Tuesday, January 19, 2038 when this number becomes 32-bit negative integer. The year 2038 problem is sometimes referred to as the Y2K38 problem. Switching to 64-bit integer will significantly extend life of Unix time because maximum value of time_t (64 bit signed integer) is 0x7FFFFFFFFFFFFFFF.
Look at the Unix time heartbeats:


Now let us test how some Linux systems are vulnerable to Y2K38 problem, using this simple code to test what happens after time_t reaches 0x7ffffff value:


#include <stdio.h>
#include <time.h>
int main(int, char **)
{
   char szBuffer[64];
   printf("Size of time_t: %d bits\n", 8*sizeof(time_t));
   time_t currentTime = time(NULL);
   struct tm * timeinfo = gmtime( &currentTime );
   printf("Unix: 0x%x value. Current UTC time: %s\n", (unsigned int)currentTime, asctime(timeinfo));
   unsigned int y38Time = 0x7fffffff;
   for(unsigned int iTime = y38Time-5; iTime < y38Time+5; iTime++)
   {
      time_t tTime = (const time_t)iTime;
      timeinfo = gmtime( &tTime );
      printf("Unix: 0x%x value. UTC time: %s", iTime, asctime(timeinfo));
   }
   return 0;
}

Test it on Ubuntu 14.04 32-bit:


8# ./y38
Size of time_t: 32 bits
Unix: 0x5fd21d1c value. Current UTC time: Thu Dec 10 13:05:32 2020

Unix: 0x7ffffffa value. UTC time: Tue Jan 19 03:14:02 2038
Unix: 0x7ffffffb value. UTC time: Tue Jan 19 03:14:03 2038
Unix: 0x7ffffffc value. UTC time: Tue Jan 19 03:14:04 2038
Unix: 0x7ffffffd value. UTC time: Tue Jan 19 03:14:05 2038
Unix: 0x7ffffffe value. UTC time: Tue Jan 19 03:14:06 2038
Unix: 0x7fffffff value. UTC time: Tue Jan 19 03:14:07 2038
Unix: 0x80000000 value. UTC time: Fri Dec 13 20:45:52 1901
Unix: 0x80000001 value. UTC time: Fri Dec 13 20:45:53 1901
Unix: 0x80000002 value. UTC time: Fri Dec 13 20:45:54 1901
Unix: 0x80000003 value. UTC time: Fri Dec 13 20:45:55 1901

The size of time_t (signed integer) is 32 bit. On 03:14:07 19 January 2038 time_t will be equal to 0x7fffffff and 1 second after will become negative and system will interpret it as 20:45:52 on Friday, 13 December 1901 rather than 03:14:08 19 January 2038. So without proper upgrade the timing of this 32 bit OS will stop working as expected.

Now what happens on CentOS 8 64 bit.


# ./y38
Size of time_t: 64 bits
Unix: 0x5fd18046 value. Current UTC time: Thu Dec 10 01:56:22 2020

Unix: 0x7ffffffa value. UTC time: Tue Jan 19 03:14:02 2038
Unix: 0x7ffffffb value. UTC time: Tue Jan 19 03:14:03 2038
Unix: 0x7ffffffc value. UTC time: Tue Jan 19 03:14:04 2038
Unix: 0x7ffffffd value. UTC time: Tue Jan 19 03:14:05 2038
Unix: 0x7ffffffe value. UTC time: Tue Jan 19 03:14:06 2038
Unix: 0x7fffffff value. UTC time: Tue Jan 19 03:14:07 2038
Unix: 0x80000000 value. UTC time: Tue Jan 19 03:14:08 2038
Unix: 0x80000001 value. UTC time: Tue Jan 19 03:14:09 2038
Unix: 0x80000002 value. UTC time: Tue Jan 19 03:14:10 2038
Unix: 0x80000003 value. UTC time: Tue Jan 19 03:14:11 2038

The size of time_t (signed integer) is 64 bit and there is no Y2K38 problem in this 64 bit OS and I expect that other 64 bit systems will be OK after Jan 19 2038 as well.

The question is how many 32 bit systems will be in use it 2038?

Leave a Reply

Your email address will not be published. Required fields are marked *