[ntpwg] Further to the timestamping issue

[Rob Seaman]

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