UNIX Time Stamp
UNIX time counts the number of seconds since an "epoch". epoch was defined as the beginning of 1970 GMT ie., January 1, 1970. This is very convenient for programs that work with time intervals: the difference between two UNIX time values is a real-time difference measured in seconds, within the accuracy of the local clock. This was standardized in POSIX
The Problem
At seven seconds past 03:14 AM on January 19, 2038 the counters on every Unix computer in the world will be full and will roll over to "0." Many computers assume the time as January 1, 1970. Because many computers store the number of seconds as a 32-bit signed integer, the Unix epoch is often said to last 231 seconds, thus ending at 03:14:07 AM January 19, 2038 (tuesday)
Storage Format & time_t
In POSIX conforming systems, the type "time_t" is used to represent times. It is an arithmetic type in C programming language. Even though there is no requirement that time_t be a 32-bit quantity, most systems define time_t as a signed 32-bit integer & many application programs may assume or store values in a 32-bit type. A signed 32-bit integer type can represent numbers ranging from -231 to 231 - 1. ie., -2,147,483,648 to 2,147,483,647. In this format, time_t will run out of positive integers 231-1 seconds (that is 24855 days, 3 hours, 14 minutes and 7 seconds) after the Epoch, in the year 2038 and thus cannot represent times beyond that point.
As a result of this, some applications written in C/C++ programming languages may then revert to 1 January 1970 as the current date, while others based on different implementation logic may revert to 13 December 1901, which is 1 January 1970 less 1031 seconds
Solution
Compiling time_t as a 64-bit signed integer will allow representation of all points in time 292 billion years before and after January 1, 1970. All new 64-bit native applications may not face "year 2038 rollover" problem
Suggested Reading:
"Bad days for software" http://www.spectrum.ieee.org/select/0998/date.html
UNIX time counts the number of seconds since an "epoch". epoch was defined as the beginning of 1970 GMT ie., January 1, 1970. This is very convenient for programs that work with time intervals: the difference between two UNIX time values is a real-time difference measured in seconds, within the accuracy of the local clock. This was standardized in POSIX
The Problem
At seven seconds past 03:14 AM on January 19, 2038 the counters on every Unix computer in the world will be full and will roll over to "0." Many computers assume the time as January 1, 1970. Because many computers store the number of seconds as a 32-bit signed integer, the Unix epoch is often said to last 231 seconds, thus ending at 03:14:07 AM January 19, 2038 (tuesday)
Storage Format & time_t
In POSIX conforming systems, the type "time_t" is used to represent times. It is an arithmetic type in C programming language. Even though there is no requirement that time_t be a 32-bit quantity, most systems define time_t as a signed 32-bit integer & many application programs may assume or store values in a 32-bit type. A signed 32-bit integer type can represent numbers ranging from -231 to 231 - 1. ie., -2,147,483,648 to 2,147,483,647. In this format, time_t will run out of positive integers 231-1 seconds (that is 24855 days, 3 hours, 14 minutes and 7 seconds) after the Epoch, in the year 2038 and thus cannot represent times beyond that point.
As a result of this, some applications written in C/C++ programming languages may then revert to 1 January 1970 as the current date, while others based on different implementation logic may revert to 13 December 1901, which is 1 January 1970 less 1031 seconds
Solution
Compiling time_t as a 64-bit signed integer will allow representation of all points in time 292 billion years before and after January 1, 1970. All new 64-bit native applications may not face "year 2038 rollover" problem
Suggested Reading:
"Bad days for software" http://www.spectrum.ieee.org/select/0998/date.html
