Time Library Organisation

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