the year 2038 problem
In computing, the year 2038 problem (also known by the numerónimo Y2K38) could cause a failure of the software in that year. The problem affects programs that use the representation of the POSIX system based on time, based on counting the number of seconds since January 1, 1970 at 00:00:00 (ignoring leap seconds).
This representation is standard in Unix-like systems and in many programs written for other operating systems due to powerful programming language C. In most 32-bit systems , the time_t data type used to store the counter second is an unsigned 32 -bit signed , ie it can represent a range of numbers between 2147483648 and 2147483647 ( -231 and 231-1 , 1 bit for the sign and 31 for the absolute value) , so the last second in this format will be represented at 3:14:07 UTC on January 19, 2038 , when the counter reaches 2 147 483 647. a second later , the counter will overflow and jump the value 147 -2 483 648 , which will cause failure of programs interpreted as being time 1901 ( depending on the implementation ) , rather than 2038. in turn, this would cause incorrect calculation and processing, and cause a problem world.
There is no simple way to fix this problem for existing combinations of CPU / OS . Change the definition of time_t to use a 64-bit type break binary compatibility for software, data storage and , usually , anything that has something to do with the binary representation of time . Change time_t to an unsigned 32 -bit integer affect programs that make calculations with time differences .
Most operating systems use 64-bit architectures to 64-bit integers time_t . Migration to these systems is still underway and is expected to be completed well before 2038. Using a 64-bit integer delay the date of issue about 2.90 billion years (2.9 x 1012 ) . That is, 220 times the approximate age of the universe.
I leave a video related with this topic!