# New definition of "Seconds Since the Epoch" in POSIX

Markus Kuhn Markus.Kuhn at cl.cam.ac.uk
Thu Feb 7 18:05:43 UTC 2002

The new 2001 edition of the POSIX standard (IEEE Std 1003.1-2001) is now
freely available online:

http://www.UNIX-systems.org/version3/

Of particular interest to all you leap second gurus out there is
perhaps the new slightly revised/relaxed definition of the technical
term "Seconds Since the Epoch" that forms the basis for the scalar time
used in Unix system calls:

http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap04.html#tag_04_14

A value that approximates the number of seconds that have elapsed since
the Epoch. A Coordinated Universal Time name (specified in terms of
seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January
1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is
related to a time represented as seconds since the Epoch, according to
the expression below.

If the year is <1970 or the value is negative, the relationship is
undefined. If the year is >=1970 and the value is non-negative, the
value is related to a Coordinated Universal Time name according to the
C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and
tm_year are all integer types:

tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
(tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400

The relationship between the actual time of day and the current value
for seconds since the Epoch is unspecified.

How any changes to the value of seconds since the Epoch are made to
align to a desired relationship with the current actual time are made is
implementation-defined. As represented in seconds since the Epoch, each
and every day shall be accounted for by exactly 86400 seconds.

What has changed?

Apart from adding the mod 100 years and mod 400 years leap year rules to
the formula, the last two paragraphs have been added. These essentially
relax the definition of Seconds Since the Epoch. Without them, a strict
interpretation of the old definition would have required that a
UTC-aware implementation (e.g., an NTP-synchronized workstation) has to
show the same progression of values during an inserted leap second
23:59:60Z and the following first second of the next day 00:00:00Z. In
other words, the wording of the old definition could have been
interpreted to require UTC-synchronized POSIX clocks to show the same
scalar timestamp at 23:59:60.5Z as well as one second later at
00:00:00.5Z, which is indeed what for example the Linux kernel did when
connected to a reference clock with activated kernel PLL.

The new definition relaxes that and allows for example an implementation
to decide to implement the progression of the scalar system time near an
inserted leap second by slowing down the system clock briefly, for
example according to the formula proposed in

http://www.cl.cam.ac.uk/~mgk25/uts.txt

As I read it, the new definition still prevents implementations from
making the system's scalar time an exact measure of physical time (e.g.
by applying the provided encoding formula to a TAI clock display,
instead of a UTC clock display) by the requirement of representing each
day by an increment of 86400 "seconds" on the scalar clock. (Though
nitpickers could of course argue that the text does not explicitely
refer to a UTC day, I know :-)

Markus

--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>