Unix epoch

The Unix epoch is the representation of points in time as the number of seconds since 00:00:00 UTC on January 1, 1970, introduced by the Unix operating system, standardised in POSIX, and later adopted by the Java programming language. One thousand million seconds after that initial instant was 01:46:40 UTC on September 9, 2001, a moment known as the Unix billennium. The Unix epoch ends GMT 03:14:07, Tuesday, January 19, 2038.

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 -2³¹ to 2³¹ - 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 2³¹ 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 isn't 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 isn't possible to predict when a leap second will be required more than a few years in advance.

POSIX time inconsistency

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 doesn't take into account leap seconds which leads to an inconsistency.

		Unix epoch
		The Unix epoch is the representation of points in time as the number of seconds since 00:00:00 UTC on January 1, 1970, introduced by the Unix operating system, standardised in POSIX, and later adopted by the Java programming language. One thousand million seconds after that initial instant was 01:46:40 UTC on September 9, 2001, a moment known as the Unix billennium. The Unix epoch ends GMT 03:14:07, Tuesday, January 19, 2038. 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 -2³¹ to 2³¹ - 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 2³¹ 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 isn't 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 isn't possible to predict when a leap second will be required more than a few years in advance. POSIX time inconsistency 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_min60 + tm_hour3600 + tm_yday86400 + (tm_year-70)31536000 + ((tm_year-69)/4)*86400 This formula doesn't take into account leap seconds which leads to an inconsistency.
Try putting this code snipplet on your page