[ntp:questions] Number of Stratum 1 & Stratum 2 Peers

Martin Burnicki martin.burnicki at meinberg.de
Wed Dec 17 09:09:15 UTC 2014

Phil W Lee wrote:
> Martin Burnicki <martin.burnicki at meinberg.de> considered Tue, 16 Dec
> 2014 12:56:15 +0100 the perfect time to write:
>> William Unruh wrote:
>>> The importance of trades is usually a before/after. And UTC TAI, GPS all
>>> have exactly the same definition of before and after. Of course if one
>>> time was in UTC and the otehr in TAI, that could well be successfully
>>> argued.
>>  From a technical point I absolutely agree with you.
>> However, there have been discussions (IIRC on the TZ or leapsecs mailing
>> lists) where folks tried to explain that even though the difference
>> between TAI and UTC is just an integral number of seconds, TAI could not
>> even be used as a replacement for UTC without leap seconds, just due to
>> specific wordings in certain documents.
> Leap seconds seem to be a real mess in the IT world.
> It would be useful if the way of inserting a leap-second was set in a
> standard, in such a way that time continued at a set rate (maybe by
> slewing at a set percentage or PPM).  If that could be achieved, it
> would remove many of the objections to leap-seconds.
> It might be difficult to thrash out in practice though.
> I know that officially at present there is an additional second
> between 23:59:60 and 00:00:00, but no time recording system that I
> know of has the ability to record times between 23:59:60 and 00:00:00
> correctly (despite such times existing since 1st Jan 1961, which must
> surely pre-date any software currently in use), which is a necessary
> requirement if the second is to be inserted exactly as currently
> specified and time continued forward (so that events are recorded in
> the correct order).
> Does anyone know of any software which will record times during that
> additional second accurately, e.g. as 23:59:60.789?

Yes, different software from Meinberg. ;-)

The main problem is that the underlying system time (often POSIX, which 
just counts seconds since an epoch) has the *same* time stamp art the 
beginning and end of the leap second.

In order to do the conversion correctly you need to know if the current 
second is the leap second, or not, i.e. you need some status flag in 
addition to the raw (e.g. POSIX) timestamp.

This is basically similar to what you have at the end of DST, where (in 
local time) a whole hour is passed twice. You need to know the DST 
status to determine unambiguously if it's the first or the second turn.

> Is there any realistic prospect of forcing software to comply with a
> time standard which includes times between 23:59:60 and 00:00:00?
> Now, you can either stipulate that all software including operation
> systems recognise times during that additional second - which would
> require re-writing the time functions of most of the worlds software
> to recognise and record times >23:59:60 < 00:00:00 (but only if a leap
> second has been legally notified), or you can agree to insert the
> additional second more gradually by clock slewing (but at what rate
> would have to be agreed).
> Clock slewing would require much more change to international
> agreements, but would require far less work on re-writing software,
> and would actually relate better to the real world, which is
> annoyingly both analogue AND irregular:-)
> Or the second itself could be redefined to take account of the actual
> speed the earth rotates - but that might be problematic for the
> scientists, as we'd likely have to keep doing it as the earth slows.
> I certainly think we need to deal with the problem better than we do
> at the moment.

A main reason for the problems with leap seconds is that POSIX has just 
ignored them when they defined their standards on timekeeping.

There has been a proposal from David Mills many years ago where the time 
during an inserted leap second increases only *very* slowly during the 
leap second, so monotonicity of time stamps is kept.

However, most algorithms, or API calls returning a time stamp plus 
consistent status information require longer execution time than just 
returning a time stamp, e.g. just a 64 bit number. So the easy way is 
often preferred over the accurate way.

I've collected some information on leap seconds in a paper which you can 
find here:


"Technical Aspects of Leap Second Propagation and Evaluation"

This may not be complete but covers many aspects of leap second handling.


More information about the questions mailing list