In POSIX conforming systems, the type time_t
is often used to represent times. It is an arithmetic type in the C programming language. There is no requirement that time_t
be a 32-bit quantity (it could be a 64-bit integer or a floating point in double format), but most systems define time_t
as a signed 32-bit integer, and many application programs may assume it, or may store values in a 32-bit type. A signed 32-bit integer type can represent numbers ranging from -231 to 231 - 1, that is, -2147483648 to 2147483647.
The time()
function returns a time_t
value that is the number of seconds since the Epoch. In this form, time() will run out of positive integers 231 seconds after the Epoch, in the year 2038 (sometime shortly after 03:00 on January 19 depending on how many leap seconds there are between 1970 and then). Programs will need to be changed to accommodate this, not unlike the Year 2000 problem. Adapting existing programs may be as easy as re-compiling them with header files that declare time_t
as a 64-bit integer, but other programs make deep assumptions as to the nature of time_t
. Also, the source code to some software packages may have been lost by then, and programmers will have to reverse engineer the software to change its date behavior. In fact, some claim that the expiration of the Unix epoch timeframe may cause more damage than was predicted for the Y2K bug.
In many ways this representation of time is awkward; because of leap seconds, it is not possible in general to say how many seconds there are between the beginning of the epoch and a particular time more than a few years in the future. This is because it is not possible to predict when a leap second will be required more than a few years in advance.
One version of POSIX was inconsistent in its handling of time because it defined "seconds since the epoch" as "the number of seconds between a specified time and the epoch", and also gave a formula for it (using integer divides):
tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400
This formula does not take into account leap seconds which leads to an inconsistency.
Search Encyclopedia
|
Featured Article
|