Rob wrote:
Martin Burnicki <martin.burni...@meinberg.de> wrote:
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.

Of course it is a hypothetical situation.  When the Unix developers
would have had the foresight to define their clock in TAI rather than
UTC, the NTP designer probably would have used TAI as well, and instead
of the leap second handling there maybe would have been some field to
broadcast the current UTC-TAI offset.

Agreed.

GPS actually does it that way.

Yes, I know. I've by myself written a set of routines which decodes and evaluates the data broadcasted by the GPS satellites.

IMO the GPS system designers have made quite a number of wise decisions, e.g. letting the GPS time simply increase monotonically, which is, from a technical/usage point of view, similar to TAI.

AFAIK the GLONASS satellites use UTC instead, which causes an interruption in the sequence of data frames whenever a leap second occurs.

Martin

_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Reply via email to