Instead of clicking on an unknown blog, how about this?
https://www.quora.com/What-is-the-Unix-32-bit-time-overflow
It’s a problem that affects UNIX systems with a 32 bit time_t data type.
The data type time_t is defined in < sys/types.h > as an integer type; the size of this type is unspecified, but it’s not specified as an unsigned type, and is therefore signed.
If the size of your integral typed (char, short, int, long, and long long are all integral types) time_t is 32 bits in width, your computer has what’s called the Year 2038 problem - Wikipedia.
The UNIX epoch is 1 January 1970. Time in time_t is measured in +/- seconds relative to that date.
This means that the 32 bit signed integer value will roll over to a negative number on 19 January 2038 at 3:14:07AM GMT, which is exactly 2,147,483,647 seconds after the epoch, and suddenly it will be 13 December 1901.
It’s not a problem on most modern UNIX systems, since time_t in modern systems is defined as a 64 bit integral type.
I personally fixed this in Mac OS X in 2004, while employed as a kernel engineer at Apple; in doing the 64 bit kernel work, I made the arbitrary decision to change the type of the field from int — 32 bits — to long — 64 bits — specifically because of this problem.
It was arbitrary, because, as a kernel change, there was no 64 bit user space at the time.
Since it’s unlikely that 32 bit systems will exist in large numbers in 2038 anyway, most other systems will have probably avoided the problem as well.
Note that this issue only impacts you if you have a 32 bit time_t, and you are using it as data type that gets serialized to storage.
Since the best current practice on storage types was a text representation for dates, since — well — forever, only programmers who ignored this at their peril will have written programs that actually suffer from this problem.
If there were a lot of these programs, then the problems probably would have been hitting us already for programs that had future dates that started out overflowed. One example might a 30 year mortgage with an incept date after 2008, which would push it into negative territory (note that I had fixed Mac OS X four years prior to that date).
Like Y2K, Y2038 is likely to be a non-event, other than a bunch of UNIX geeks having “End Of The World” parties the weekend before that Tuesday rolled around.
I suspect there may also bee some “inside joke” T-shirts sold as the day approaches…
The World Ends On A Tuesday
Pass It On
Unix systems have used a timer based on clock ‘ticks’
The starting (0) clock tick was set at January 1 1970.
Unix Time is represented by a 32 bit whole number (an integer) that can be positive or negative (signed). Unix was originally developed in the 60s and 70s so the “start” of Unix Time was set to January 1st 1970 at midnight GMT (Greenwich Mean Time) - this date/time was assigned the Unix Time value of 0. This is what is know as the Unix Epoch.
The 32 bit number will overflow and set back to 0 in the year 2036
Ping