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

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

Rob wrote:
> Martin Burnicki <martin.burnicki at meinberg.de> wrote:
>> 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.
> Yes, but in situations where you care about that you store just the
> system time, and the conversion to local time can be repeated later.
> Thanks to the powerful conversion routines in glibc this can be done
> even way in the past (because it remembers DST rules from previous years).

Agreed, for this case it works, due to effort of the tzdata maintainers.

> Unfortunately, the same mechanism isn't used for leap seconds.
> There would be no problem at all when the system time ticked in TAI
> and the addition of the leap seconds is done via some rule table similar
> to the local time rules.  ntpd would not even be involved in the problem.

Also agreed. However, actually ntpd expects UTC, not TAI.

In spite of this it may eventually work if you set up an NTP server 
where the system time runs on TAI and you use one of the "right" time 
zones which are also part of the tzdata package. I haven't tried this.

You'd have to take care that ntpd does *not* announce leap seconds in 
this case, but you'd have to update the leap second information anyway, 
since otherwise the conversion done according to the "right" time zone 
rules would be wrong. ;-)

>> A main reason for the problems with leap seconds is that POSIX has just
>> ignored them when they defined their standards on timekeeping.
> That is the problem.  And probably also the decision in Unix to count
> UTC seconds since Jan 1st, 1970 (instead of TAI seconds).
> Back then it did not matter that much in a timesharing system.  The
> system clock was mainly a convenience feature, not critical to anything.
> (it usually had to be set on every boot and this was done by typing
> the time seen on the operator's wristwatch, hence the term "wristwatch time")

Again agreed. Using TAI for sytem time and a current leap second table 
would allow to convert TAI to UTC unambiguously. I think that's what the 
conversion routines do for the "right" timezones.

On the other hand, maybe you have seen the discussions elsewhere why you 
can't use TAI for the system time for hypothetical reasons. Or at least 
you can't call it "TAI".


More information about the questions mailing list