# Unix Time and Leap Seconds

#### Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

•  Subject
• Author
• Posted on
I have Red Hat Enterprise Linux 4.

Is it true on my system that the Unix time may skip up or down by one second
at midnight when there is a leap second?

By "Unix time" I mean the integer returned by time() and similar functions.

I'm concerned about the "down" case.  Some of the software I've written
assumes monotonically-increasing time.

Thanks.
--
David T. Ashley              (dta@e3ft.com)
http://gpl.e3ft.com (GPL Publications and Projects)

## Re: Unix Time and Leap Seconds

On Sat, 23 Jun 2007 01:04:46 -0400 David T. Ashley said

I don't think you have to worry.

(1) NIST says "Based on what we know about the earth's rotation, it seems
unlikely that we will ever have a negative leap second."
<http://tf.nist.gov/general/leaps.htm#Anchor-52904

(2) If it did happen, the time would repeat, not go backwards.

Sig

--
http://koiclubsandiego.org/comment/?r=8
9b9a436ac9285567ef58d7d6a4dbb750

## Re: Unix Time and Leap Seconds

If I'm understanding your comment correctly, and if I'm not mixed up myself,
I believe you have the sign wrong in the way you're thinking about leap
seconds.  An ordinary (positive) leap second is where you insert an extra
second and "time stands still" for a second (this is akin to February 29).
I believe these will get more frequent as the earth's rotation is slowing
down.

An ordinary leap second ("time stands still") actually in effect gives the
earth's rotation time to "catch up" to the kept time.

A negative leap second would result in the Unix time skipping a second
(jumping forward).

Of course, "time standing still" can't happen on a computer system, so you
have to re-use a Unix time value (i.e. Unix time goes backwards).

So, I believe but am not sure that due to a sign mixup, the case that you
have presented as impossible is actually the normal and expected case.

According to the entry on Wikipedia,

http://en.wikipedia.org/wiki/Unix_time

Unix time will re-use certain integers when a leap second occurs.  That
surprised me, but it may very well be true.

My application is generating unique identifiers in PHP (as part of web
database scripts).  The current scheme I use is:

a)Concatenate the integer seconds time, the microtime, and the process PID,
and then

b)Spin lock or micro_sleep() until the microtime changes.

The identifiers generated should be unique because no two processes can have
the same PID at the same time.

I think the workaround I'll use (because leap seconds are handled at
midnight UTC) is that if I get an integer seconds time that is too close to
a midnight (i.e. mod 86400 is <=1 or >=86398), then I'll just sleep until it
gets out of that range.  That leaves approximately 4 seconds near midnight
UTC where a web page load may hang for up to 4 seconds.  That seems very
tolerable, because the window is so narrow and because the web page will

Anyone want to throw rocks at me and tell me I'm crazy?

Thanks for all input.

Dave.
--
David T. Ashley              (dta@e3ft.com)
http://gpl.e3ft.com (GPL Publications and Projects)

## Re: Unix Time and Leap Seconds

On Sat, 23 Jun 2007 10:44:14 -0400 David T. Ashley said

You're right, I was over hasty (and backwards) in my interpretation of NIST's
positive and negative.

However, ignoring the issue of local clock correction, brought up elsewhere in
this thread, my comment on monotonicity stands. The seconds count will repeat,
rather than go backwards.

--
http://koiclubsandiego.org/comment/?r=8

## Re: Unix Time and Leap Seconds

Fair enough.  However, for my application (where I use the microtime as
well), time repeats rather than being monotonic.  For my application, it
would be possible that I get a duplicate (seconds, microtime) pair.

(seconds) is monotonic (I agree with you).

(seconds.microtime) is not monotonic.

--
David T. Ashley              (dta@e3ft.com)
http://gpl.e3ft.com (GPL Publications and Projects)

## Re: Unix Time and Leap Seconds

David T. Ashley wrote:

Daylight saving (though how calling one time another saves daylight - there
will be exactly the same amount of daylight in the day regardless of what
you call the hours - I'm still trying to work out) are specified in a config
file (mefinx) and rarely change.  Leap seconds I'm not so sure about - they
seem to be added semi-randomly (as and when the extremely constant and
accurate (for some definition of accurate) atomic clocks' day gets behind of
the slowing down earth rotation day).

Leap seconds will then mean that your clock is 1 second fast.

Personally I think you've probably got more concern from using a time server
to sync your computer's clock - the clock in this PC, for example, gains
quite a bit and so resyncing it adjusts it downward every time.

If you've got software that assumes monotonically increasing time, I'd
recommend you get a PC with a clock that loses time (ie it ticks at 1.00001
secs, as opposed to the 0.99999 secs of this PC) so that when re-syncing
your clock it will always adjust upwards.  Besides, on a GHz processor,
seconds are rather a coarse measure anyway.

## Re: Unix Time and Leap Seconds

Robert Newson wrote:
though how calling one time another saves daylight -

... tedious rhetoric ...

## Re: Unix Time and Leap Seconds

On Sat, 23 Jun 2007, in the Usenet newsgroup comp.os.linux, in article

[compton ~]\$ whatis time
time                 (2)  - get time in seconds
[compton ~]\$

Neither UTC or 'time(2)' know anything about Daylight Saving Time

From the 'leapsecond' file in the timezone source file tzdata2007f.tar.gz
available from ftp://elsie.nci.nih.gov/pub/

# YEAR  MONTH DAY   HH:MM:SS  CORR    YEAR  MONTH DAY   HH:MM:SS  CORR
1972  Jun   30    23:59:60  +       1972  Dec   31    23:59:60  +
1973  Dec   31    23:59:60  +       1974  Dec   31    23:59:60  +
1975  Dec   31    23:59:60  +       1976  Dec   31    23:59:60  +
1977  Dec   31    23:59:60  +       1978  Dec   31    23:59:60  +
1979  Dec   31    23:59:60  +       1981  Jun   30    23:59:60  +
1982  Jun   30    23:59:60  +       1983  Jun   30    23:59:60  +
1985  Jun   30    23:59:60  +       1987  Dec   31    23:59:60  +
1989  Dec   31    23:59:60  +       1990  Dec   31    23:59:60  +
1992  Jun   30    23:59:60  +       1993  Jun   30    23:59:60  +
1994  Jun   30    23:59:60  +       1995  Dec   31    23:59:60  +
1997  Jun   30    23:59:60  +       1998  Dec   31    23:59:60  +
2005  Dec   31    23:59:60  +

Relatively random, no?

You seem to be posting from a Linux box - see the TimePrecision-HOWTO
which should be on your system (or get it from the LDP).

You really want to look at the NTP client documentation, or even

adjtimex             (2)  - tune kernel clock
adjtimex             (8)  - display or set the kernel time variables
[compton ~]\$

as well as how "time" is measured - it has nothing to do with the CPU
clock frequency.  "INT0" (cat /proc/interrupts) is generated by a
separate (equally crappy) oscillator.

Old guy

## Re: Unix Time and Leap Seconds and daylight savings time

Robert Newson wrote:

...
...

When a sample of Iowa farmers were asked about the effect of
increasing the amount of daylight savings time this year, a fair
number said that it would make the summer hotter because there
would be more sunlight to warm the earth.  They were evenly
divided if this was a good thing or not.

bill

## Re: Unix Time and Leap Seconds and daylight savings time

bill wrote:

Another urban legend.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

## Re: Unix Time and Leap Seconds and daylight savings time

On 27.06.2007 15:33 Jerry Stuckle wrote:

That was an example of so-called "joke", Jerry. ;))

--
gosha bine

blok ~ http://www.tagarga.com/blok

## Re: Unix Time and Leap Seconds and daylight savings time

gosha bine wrote:

Sorry, but that can be pretty sensitive to those of us who grew up in
Iowa - and have had people believe it as a fact, not a joke.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

## Re: Unix Time and Leap Seconds and daylight savings time

Jerry Stuckle wrote:

Apologies to all who grew up in Iowa, it was really about
Illinois farmers.

bill

## Re: Unix Time and Leap Seconds

David T. Ashley wrote:

Bad programming.  What happens, for instance, if the clock on your
server is "corrected" back five seconds (possibly because it's running
fast)?

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

## Re: Unix Time and Leap Seconds

wrote:

Well, that in turn would be bad server administration, since NTP tries to do
this by slowing the clock to maintain monotonic time - you have to be off by
minutes before it resorts to going backwards (and even then there's an option
to prevent it).

--
Andy Hassall :: andy@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

## Re: Unix Time and Leap Seconds

Andy Hassall wrote:

No, not at all.

First of all, servers do not have clocks with the accuracy of 1 second
in 10M years.

So they have to be adjusted.  And even though NTP tries to speed up and
slow the clock - it's not perfect.  And at times the clock WILL jump
forwards or backwards at least one second.

Of course, you are assuming:

1) they are running Linux or another Unix variant,
2) NTP server the system is using to set the clock is accurate (not
necessarily the case - most are (at least) second or third tier servers,
3) the network delay between the system and the NTP server is constant
and measurable...
4) The hardware allows the adjustment,
5) The adjustment is within the limits allows (typically 512 ppm, but
this can vary)...

I could continue.  The point is - you can't pawn this off on the
administrator.  There are a lot of things out of his control.

And programming such that you require the clock to continue incrementing
is a recipe for problems later.  No there have not be3en any "unleap
seconds" yet.  But that doesn't mean there can't  be.

And while I agree with the astronomers that there is no reason for a
negative leap-second, programmers need to be aware it can happen!

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

## Re: Unix Time and Leap Seconds

Jerry Stuckle wrote:

...

Shirley the correction for a negative leap-seacond would be to put the clock
/forward/ 1 second?  ie /increase/ the time?[1]

The only thing is: does the time() clock actually adjust for leap seconds?
Leap days (and DLS) are "fixed" in the conversion to localtime; would leap
seconds be "fixed" at the same time?

[1] Consider that what leap days do is cause the day to be fast if you don't
correct; the "correction" causes 1 Mar becomes 29 Feb, 2 Mar becomes 1 Mar,
etc - the "correction" is to take the clock /backward/ by 86,400[2] seconds
by inserting an extra 86,400 seconds.  Similarly leap-seconds: they insert a
second to take the clock backwards: the [physical] day is 86,401[2] seconds
long (24:00:01); a negative leap-second would require the day to be
86,399[2] seconds long (23:59:59) - the only way this could shirley occur is
if the earth's rotation /speeded up/...or the timekeepers (atomic clocks?)
slowed down[3]?
[2] Rounded to the nearest second.
[3] Or an error was made in adding a leap second in the first place?

Or have I totally misunderstood what leap seconds (and days) do?

## Re: Unix Time and Leap Seconds

Robert Newson wrote:

Don't call me Shirley! :-)

In the case of a leap second, yes.  But you took my statement out of
context.  Leap seconds are not the only reason computer clocks may need

I don't know, but I would hope so.  The problem is that leap seconds are
not fixed.  They are added when necessary.

In the case of leap seconds.  But read the rest of my message.

Also, leap seconds are added because the earth's rotation is slowing
down due to the drag from the moon's gravity.  But there is nothing to
say it couldn't speed up.  Of course to do that would probably require
something like a glancing blow from a large asteroid - in which case I
doubt we would be worrying about a few seconds on a computer clock :-)

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

## Re: Unix Time and Leap Seconds

Jerry Stuckle wrote:

...

Something similar did occur to me - that if a negative leap second had to be
added, the cause of the requirement would be such that the actual clock
adjustment would be the least of anyone's worry...unfortunately, I seem to
have cut that bit from my reply. ^_^

## Re: Unix Time and Leap Seconds

No. Earthquakes reaarange the mass distribution of the earth, heating of
the atmosphere rearranges the mass distribution of the earth, etc. Ie there
are lots of things other than asteroids that could speed up or slow down
the rotation of the earth to parts per 10^8