[LEAPSECS] POSIX Time (was WP7A)

[Poul-Henning Kamp]

In message <p06240805c6f79d590aaa@[192.168.1.212]>, Joe Gwinn writes:


>My point is that even though the POSIX timescale Epoch is defined in 

>UTC, that does not make the POSIX timescale the same as UTC. 


I feel compelled to quote, at length, what The Open Group has to
say on this subject, since appearantly a number of people have
not actually read this stuff.

Please do so now, so we get a facts based discussion.

Poul-Henning

Epoch

Historically, the origin of UNIX system time was referred to as
"00:00:00 GMT, January 1, 1970". Greenwich Mean Time is actually
not a term acknowledged by the international standards community;
therefore, this term, "Epoch", is used to abbreviate the reference
to the actual standard, Coordinated Universal Time.


 A.4.14 Seconds Since the Epoch

Coordinated Universal Time (UTC) includes leap seconds. However,
in POSIX time (seconds since the Epoch), leap seconds are ignored
(not applied) to provide an easy and compatible method of computing
time differences. Broken-down POSIX time is therefore not necessarily
UTC, despite its appearance.

As of September 2000, 24 leap seconds had been added to UTC since
the Epoch, 1 January, 1970. Historically, one leap second is added
every 15 months on average, so this offset can be expected to grow
steadily with time.

Most systems' notion of "time" is that of a continuously increasing
value, so this value should increase even during leap seconds.
However, not only do most systems not keep track of leap seconds,
but most systems are probably not synchronized to any standard time
reference. Therefore, it is inappropriate to require that a time
represented as seconds since the Epoch precisely represent the
number of seconds between the referenced time and the Epoch.

It is sufficient to require that applications be allowed to treat
this time as if it represented the number of seconds between the
referenced time and the Epoch. It is the responsibility of the
vendor of the system, and the administrator of the system, to ensure
that this value represents the number of seconds between the
referenced time and the Epoch as closely as necessary for the
application being run on that system.

It is important that the interpretation of time names and seconds
since the Epoch values be consistent across conforming systems;
that is, it is important that all conforming systems interpret
"536457599 seconds since the Epoch" as 59 seconds, 59 minutes, 23
hours 31 December 1986, regardless of the accuracy of the system's
idea of the current time. The expression is given to ensure a
consistent interpretation, not to attempt to specify the calendar.
The relationship between tm_yday and the day of week, day of month,
and month is in accordance with the Gregorian calendar, and so is
not specified in POSIX.1.

Consistent interpretation of seconds since the Epoch can be critical
to certain types of distributed applications that rely on such
timestamps to synchronize events. The accrual of leap seconds in a
time standard is not predictable. The number of leap seconds since
the Epoch will likely increase. POSIX.1 is more concerned about the
synchronization of time between applications of astronomically short
duration.

Note that tm_yday is zero-based, not one-based, so the day number
in the example above is 364. Note also that the division is an
integer division (discarding remainder) as in the C language.

Note also that the meaning of gmtime(), localtime(), and mktime()
is specified in terms of this expression. However, the ISO C standard
computes tm_yday from tm_mday, tm_mon, and tm_year in mktime().
Because it is stated as a (bidirectional) relationship, not a
function, and because the conversion between month-day-year and
day-of-year dates is presumed well known and is also a relationship,
this is not a problem.

Implementations that implement time_t as a signed 32-bit integer
will overflow in 2038. The data size for time_t is as per the ISO
C standard definition, which is implementation-defined.

See also Epoch.

The topic of whether seconds since the Epoch should account for
leap seconds has been debated on a number of occasions, and each
time consensus was reached (with acknowledged dissent each time)
that the majority of users are best served by treating all days
identically. (That is, the majority of applications were judged to
assume a single length-as measured in seconds since the Epoch-for
all days. Thus, leap seconds are not applied to seconds since the
Epoch.) Those applications which do care about leap seconds can
determine how to handle them in whatever way those applications
feel is best. This was particularly emphasized because there was
disagreement about what the best way of handling leap seconds might
be. It is a practical impossibility to mandate that a conforming
implementation must have a fixed relationship to any particular
official clock (consider isolated systems, or systems performing
"reruns" by setting the clock to some arbitrary time).

Note that as a practical consequence of this, the length of a second
as measured by some external standard is not specified. This
unspecified second is nominally equal to an International System
(SI) second in duration. Applications must be matched to a system
that provides the particular handling of external time in the way
required by the application.

IEEE Std 1003.1-2001/Cor 2-2004, item XBD/TC2/D6/12 is applied,
making an editorial correction to the paragraph commencing "How any
changes to the value of seconds ...".


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.