Here is some history:

The earliest versions of Unix time had a 32-bit integer incrementing at a rate of 60 Hz, which was the rate of the system clock on the hardware of the early Unix systems. The value 60 Hz still appears in some software interfaces as a result. The epoch also differed from the current value. The first edition Unix Programmer's Manual dated November 3, 1971 defines the Unix time as "the time since 00:00:00, Jan. 1, 1971, measured in sixtieths of a second". It also comments that "the chronologically-minded user will note that 232 sixtieths of a second is only about 2.5 years". Because of this limited range, the epoch was redefined more than once, before the rate was changed to 1 Hz and the epoch was set to its present value. This yielded a range in excess of 130 years, though with more than half the range in the past (see discussion of signedness above).


As indicated by the definition quoted above, the Unix time scale was originally intended to be a simple linear representation of time elapsed since an epoch. However, there was no consideration of the details of time scales, and it was implicitly assumed that there was a simple linear time scale already available and agreed upon. Indeed, the first edition manual's definition doesn't even specify which timezone is used. Several later problems, including the complexity of the present definition, result from Unix time having been defined gradually by usage rather than fully defined to start with.


When POSIX.1 was written, in the 1980s (it was published in 1988), the question arose of how to precisely define time_t in the face of leap seconds. Some argued for it to remain, as intended, a linear count of seconds since the epoch, at the expense of complexity in conversions with civil time. Others argued for it to remain, as conflictingly intended, easily interconvertible with the conventional representation of civil time, at the expense of inconsistency around leap seconds. Computer clocks of the era were not sufficiently precisely set to form a precedent one way or the other. The POSIX committee was swayed by arguments against complexity in the library functions, and firmly defined the Unix time in a simple manner in terms of the elements of UTC time. Unfortunately, this definition was so simple that it didn't even encompass the entire leap year rule of the Gregorian calendar, and would make 2100 a leap year.


The 2001 edition of POSIX.1 rectified the faulty leap year rule in the definition of Unix time, but retained the essential definition of Unix time as an encoding of UTC rather than a linear time scale. Also, since the mid-1990s computer clocks have been routinely set with sufficient precision for this to matter, and they have most commonly been set using the UTC-based definition of Unix time. This has resulted in considerable complexity in Unix implementations, and in the Network Time Protocol, in order to execute steps in the Unix time number whenever leap seconds occur.
In 2004 POSIX added new interfaces making several different time scales available to programs, splitting up the many uses to which Unix times have traditionally been put. The future is one where time values are accompanied by explicit labels of the time scale defining their significance. Unix time as described in this article will still be in wide use for decades to come, but is likely to be increasingly treated as a legacy system and superseded by better-defined systems.