[ntpwg] Further to the timestamping issue

[David L. Mills]

Rob,

I don't understand your comment. The IERS can surely announce any future 
leap epoch, but from the current draft of the relevant ITU-T and NIST 
recommendation, there are no provisions with public dissemination means 
to announce other than in June or December. The WWV/H/B and ACTS leap 
warning indicators apply at the end of the current month, which is how 
the leap warning bits are interpreted in NTP. From past experience, 
server leap warning bits have had less than perfect reliability and 
represent a possible vulnerability. This is why the upstratum servers 
vote on the leap warning bits and are  reluctant to set their own leap 
warning bits other than on the day of the leap.

Dave

Rob Seaman wrote:

> On Jun 19, 2008, at 8:04 AM, TSG wrote:
>
>>> My fundamental point is that UTC permits much more flexible leap
>>> second scheduling than has been demonstrated to date. NTP might have
>>> to adapt to this in the future.
>>
>> Not if its used in proper auditing of IT operations. Leap Seconds
>> are a nightmare for logging systems because they require special
>> handling and integration across an entire entitie's operations.
>
>
> I don't discount auditing requirements, although it isn't clear that
> NTP's requirements are the same as your company's. That the Earth
> orbits the Sun and has a large nearby Moon are a bit more fundamental
> than either. We can disagree about the implications of all sorts of
> requirements. Basing a discussion on requirements is generally more
> productive, however, than jumping directly into each other's nightmares.
>
> NTP already provides special handling and integration for the case of
> leap seconds. That being the case, it certainly would be appropriate
> to update the system should the underlying UTC leap second
> implementation ever change. This is not imminent, but seems
> ultimately more likely than the current fad for advocating the
> elimination of leap seconds in a fruitless attempt to abandon mean
> solar time.
>
> In any event, NTP either supports UTC or it doesn't. This is also a
> requirement, whatever complications that causes elsewhere. Required
> complexity is another name for "design".
>
> In short, UTC *already* permits multiple leap seconds to be announced
> in advance. with an arbitrarily longer horizon than six months. NTP
> systems *already* fail to implement the full complexity implicit in UTC.
>
> Rob Seaman
> NOAO
>
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg