It is almost always manipulated as a signed 32-bit integer number. In this form, the epoch will run out in the year 2038 (sometime shortly after 03:00 on January 19 depending on how many leap seconds there between 1970 and then). Programs will need to be changed to accomodate, not unlike the Year 2000 problem.
In POSIX the type time_t is often used to represent times. It is a type in the C programming language. In POSIX the time() function returns a time_t value that is the number of seconds since the Epoch (and time_t is an arithmetic type).
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 many application programs may assume it, or may store values in a 32-bit type.
Programs that make few assumptions about the type time_t will probably not require modification to work with times beyond 2038; just requiring software to be recompile?d using updated libraries (with a wider time_t type) rather than requiring changes to the source code.
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):
![[Home]](wikipedia.png)
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.