Time Library Organisation

[Ketil Malde]

Ashley Yakeley <ashley at semantic.org> writes:

> It seems what should have been done was to create a patch to the 
> kernel that allows the hardware clock to run on TAI but have 
> gettimeofday return broken time as per POSIX, and have some other 
> function to return TAI time. Perhaps someone's done this.

I tried to find out, with no success.  Anybody?  I'm about to
reinstall my Linux laptop after a disk crash, so I could try to do
this. It also appears that support is needed in NTP, although I'm not
sure why. 

> Of course, even if the available clock uses broken POSIX UTC time,
> users might still want a leap-second table to convert to TAI.

I don't think UTC is broken, only POSIX and its time_t representation
which quietly moves pushes the epoch a bit forward every leap second.
UTC is the calendar specification, and not a counter, right?
(I.e. UTC specifies the second "1998-12-30T23:59:60" as a perfectly
good, normal second, while the corresponding POSIX time_t (and NTP
second) is ambigous, and could mean the next (or previous?) second as
well.)

Am I the only one who feels that a calendar, unlike a clock, should
specify particular time units (e.g. a particular day, hour, or
second), and not infinitesimal points in time?  

So I would distinguish between the day "1998-12-30" and the hour
"1998-12-30T00", for instance.  I think this fits better with the
applications I can imagine, but perhaps I'm a bit short on
imagination? 

-kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants