Re: [LEAPSECS] Mechanism to provide tai-utc.dat locally

From: Zefram <zefram_at_fysh.org>
Date: Wed, 27 Dec 2006 13:13:32 +0000

Ashley Yakeley wrote:
>On Dec 27, 2006, at 01:23, Clive D.W. Feather wrote:
>>Any proposal has got to deal with a whole load of issues, many of which
>>haven't been properly documented. For example, it should be possible to add
>>and subtract times and intervals (e.g. "what time is 14 months and 87 days
>>from now?").

It should also be possible to say "what time is 10^7 seconds from now?".
To do arithmetic with all these units requires several different
representations of time.

>In the Haskell time library, I represent UTC time by what seemed to
>me the simplest possible correct type. This is a record containing an
>integer to represent day number (as MJD), and a fixed-point decimal
>(picosecond resolution) to represent seconds since midnight. The
>allowed range for this is 0 to 86400.999999999999.

That's a pretty good format.

>call to get the current UTC time relies on gettimeofday, so it is
>unavoidably off by up to a second during a leap-second insertion.

It's possible to fix this up by using ntp_adjtime(3). This gives the
Unix time (except on some systems where it doesn't and you have to
use ntp_gettime(3) for that bit) plus a state variable from the leap
second system. See my Perl module Time::UTC::Now for the logic required
to decode it.

> Therefore I have the concept of "nominal UTC difference". For
>instance, between 2005-12-31 23:00 UTC and 2006-01-01 01:00 UTC there
>were two hours and one second of time, but only two hours of nominal
>UTC time.

This is essentially a calendar difference. In that range you have
exactly two calendar hours, one of which is 3601 s long. It's just like
saying that the interval between 2006-01-01T00Z and 2006-03-01T00Z is two
(calendar) months, where the two months are of different lengths.

In the general case: to determine or use an interval of N calendar FOOs,
it is convenient to represent the time as a linear count of calendar
FOOs plus details of the exact position within the current FOO. FOO may
be minute, hour, day, week, month, or year. I think there should be
record formats for all of these cases (the native UTC format is one of
these with FOO = day), with conversion functions between them and also
a linear count of seconds. Then the user of the API can do eir own
arithmetic on the linear counts.

-zefram
Received on Wed Dec 27 2006 - 05:14:01 PST