[LEAPSECS] POSIX and C (Was: Re: ISO Influence)

Paul Sheer p at 2038bug.com
Sun Dec 19 02:07:40 EST 2010

I don't know how many on this list program or not in C, so here is some
background that may assist....

There are three POSIX functions which convert between broken down time
format (aka YYYY-MM-DD HH:MM:SS) to a seconds-since-1970 scalar value.

They are gmtime(), localtime(), and mktime()

gmtime() converts seconds to broken down time in terms of zero hours
offset from greenwich.

localtime() converts seconds to broken down time in terms of the local
timezone. (Obviously the most commonly used of the functions)

mktime() is the inverse of localtime().

There is no fourth function to do the inverse of gmtime().

For this and other reasons many programs implement their own function to
do this. They would assume 86400 seconds per day to copy POSIX or
because they have never heard of leap seconds. I would guess there are
an enormous number of statically linked executables that contain such

At this "late" stage in Unix software evolution the genie is out of the
bottle. You can change the standard to whatever you like, but I guess
few would comply.

POSIX time (as implemented) does not conform to any time standard, and
explains this in section "A.4.14 Seconds Since the Epoch".
Unfortunately, this section is in the Rationale part of POSIX 3, so few
people would ever look at it. In the "General Concepts" section it just
says that there are 86400 seconds in every day.

POSIX mentions UTC *only* to explain the general sense of POSIX's
meaning: i.e. the general sense of counting seconds from 1970 rather
than some other date like 1900.

POSIX time has now evolved by consensus to (usually) mean: "we tick over
with TAI, except on a leap second where we pause for one full second".
And software is usually written to be robust enough to deal with the
pause. The NTP server performs this pause.

I don't think this consensus is defined in any standard. Anyone?

I think A.4.14 has been posted before, but it is such gorgeous poetry I
can't help posting it again. Kudus to the POSIX authors for their
pragmatic attitude.

FWIW, in spite of all of this, I myself favor the continued broadcast of
leap seconds.


A.4.14 Seconds Since the 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



More information about the LEAPSECS mailing list