- Year 2038 problem
The Year 2038 problem is an issue for computing and data storage situations in which time values are stored or calculated as a signed 32-bit integer, and the number is interpreted as the number of seconds since 00:00:00 UTC on 1 January 1970 (the epoch). Systems working on 32-bit cannot encode times after 03:14:07 UTC on 19 January 2038, analogous to the Y2K problem , in which 2-digit values representing the number of years since 1900 could not encode the year 2000 or later. Most 32-bit Unix like systems store and manipulate time in this Unix time format, so the year 2038 problem is sometimes referred to as the Unix Millennium Bug by association.
- What is Unix time?
The Unix epoch time is the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap seconds . Literally speaking the epoch is Unix time 0 (midnight 1/1/1970), but ‘epoch’ is often used as a synonym for ‘Unix time’. Many Unix systems store epoch dates as a signed 32-bit integer, which might cause problems on January 19, 2038 (known as the Y2038).
- Data structures with time problems
- 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 file systems 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.
- Solutions:
Most operating systems designed to run on 64-bit hardware already use signed 64-bit time_t integers. Using a signed 64-bit value introduces a new wraparound date that is over twenty times greater than the estimated age of universe.
(age of universe: approximately 292 billion years from now, at 15:30:08 UTC on Sunday, 4 December 292,277,026,596.)
for more information refer:Wikipedia
Comments
Post a Comment