On Sun, 7 Jan 2007, M. Warner Losh wrote:
>
> Having tried it, there are a lot of little 33 second anomolies in many
> applications :-(.
How did you extend the UTC translation back past 1972 if the undelying
clock followed TAI? I assume that beyond some point in the past you say
that the clock times are a representation of UT. However TAI matched UT in
1958 and between then and 1972 you somehow have to deal with a 10s offset.
It would be over-engineering to implement rubber seconds for the whole
system when only very few applications need them. I suppose you could
invent a leap second schedule for the 1960s, but perhaps it's more
sensible to define the underlying timescale to be TAI+10 so that your
system makes the universal->atomic time split at the point when UTC was
established.
> I've toyed with the idea of running the kernel in TAI and having 'smart'
> processes tell libc they want no UTC translation and having all the
> TAI<->UTC translation happen in libc (also hacking those FS that want
> UTC time to be able to get it).
It would seem sensible to me to fix time_t's lack of range at the same
time as fixing its model of time. Perhaps the transition model to follow
is the one used on non-BSD systems for large file support, which allows
the developer to either set a compile time flag to get the new behaviour,
or use a wide form of the API, e.g. stat64() instead of stat().
Tony.
--
f.a.n.finch <dot_at_dotat.at> http://dotat.at/
ROCKALL: SOUTHWEST 6 BECOMING CYCLONIC 6 TO GALE 8, PERHAPS SEVERE GALE 9
LATER. VERY ROUGH BECOMING HIGH. SHOWERS, RAIN LATER. MODERATE OR GOOD.
Received on Sun Jan 07 2007 - 16:26:36 PST