[181434] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: REMINDER: LEAP SECOND

daemon@ATHENA.MIT.EDU (Philip Homburg)
Wed Jun 24 09:35:29 2015

X-Original-To: nanog@nanog.org
To: Tony Finch <dot@dotat.at>
From: Philip Homburg <pch-nanog@u-1.phicoh.com>
In-reply-to: Your message of "Wed, 24 Jun 2015 14:05:34 +0100 ."
 <alpine.LSU.2.00.1506241358180.3102@hermes-1.csi.cam.ac.uk> 
Date: Wed, 24 Jun 2015 15:34:53 +0200
Cc: nanog2 <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org

In your letter dated Wed, 24 Jun 2015 14:05:34 +0100 you wrote:
>Philip Homburg <pch-nanog@u-1.phicoh.com> wrote:
>>
>> For UTC the analog approach would be to keep time in TAI internally and
>> convert to UTC when required.
>
>This is much less of a solution than you might hope, because most APIs,
>protocols, and data formats require UT. (Usually not UTC but a
>representation isomorphic to traditional UT which ignores leap seconds.)

Supporting legacy formats can be annoying. In some cases it would be no
problem. For example NTP. If there is a defined way to convert between TAI
and UTC then converting TAI to NTP timestamps is easy except during an
actual leap second. Which is not really a problem.

Unix systems would probably need a few new system calls to accept time in TAI.

File formats like tar are unlikely to matter much: find a consistent way of
encoding time around the leap second and most likely nobody will care.

In any case, it would be nice if future formats and systems could have a 
sensible time keeping system. 



home help back first fref pref prev next nref lref last post