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 <[EMAIL PROTECTED]> 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.
