2038
Unix stores system time values as the number of seconds from midnight 1 January 1970 (the "Unix Epoch") in variables of type time_t, historically defined as "signed long". On 19 January 2038 on 32 bit Unix systems, the current time will roll over from a zero followed by 31 ones (0x7FFFFFFF) to a one followed by 31 zeros (0x80000000), which will reset time to the year 1901 or 1970, depending on implementation, because that toggles the sign bit.
Since times before 1970 are rarely represented in Unix time, one possible solution that is compatible with existing binary formats would be to redefine time_t as "unsigned 32-bit integer". However, such a kludge merely postpones the problem to 7 February 2106, and could introduce bugs in software that computes time differences.
Some Unix versions have already addressed this. For example, in Solaris and Linux in 64-bit mode, time_t is 64 bits long, meaning that the OS itself and 64-bit applications will correctly handle dates for some 292 billion years. Existing 32-bit applications using a 32-bit time_t continue to work on 64-bit Solaris systems but are still prone to the 2038 problem. Some vendors have introduced an alternative 64-bit type and corresponding API, without addressing uses of the standard time_t. The NetBSD Project decided to instead bump time_t to 64-bit in its 6th major release for both 32-bit and 64-bit architectures, supporting 32-bit time_t in applications compiled for a former NetBSD release via its binary compatibility layer.