Y2038 Bug

The furthest time that a signed 32-bit integer can represent the Unix time format is 03:14:07 UTC on Tuesday, 19 January 2038 (2147483647 seconds after 1 January 1970).
As of 2012, most embedded systems use 8-bit or 16-bit microprocessors, even as desktop systems are transitioning to 64-bit systems.
MySQL database's inbuilt functions like UNIX_TIMESTAMP() will return 0 after 03:14:07 UTC on 19 January 2038.

Many data structures in use today have 32-bit time representations embedded into their structure. A full list of these data structures is virtually impossible to derive but there are well-known data structures that have the Unix time problem:

    file systems (many filesystems use only 32 bits to represent times in inodes)
    binary file formats (that use 32-bit time fields)
    databases (that have 32-bit time fields)
    database query languages, like SQL that have UNIX_TIMESTAMP() like commands
    COBOL systems of 1970s - 1990s vintage that have not been replaced by 2038-compliant systems
    embedded factory, refinery control and monitoring subsystems
    assorted medical devices
    assorted military devices

Each one of these places where data structures using 32-bit time are in place has its own risks related to failure of the product to perform as designed.

There is no universal solution for the Year 2038 problem. Any change to the definition of the time_t data type would result in code compatibility problems in any application in which date and time representations are dependent on the nature of the signed 32-bit time_t integer. For example, changing time_t to an unsigned 32-bit integer, which would extend the range to the year 2106, would adversely affect programs that store, retrieve, or manipulate dates prior to 1970, as such dates are represented by negative numbers. Increasing the size of the time_t type to 64-bit in an existing system would cause incompatible changes to the layout of structures and the binary interface of functions.