On Tue, Jul 05, 2005 at 06:47:41PM -0600, zowie wrote: : Hmmm.... Actually, ntpd achieves that sort of accuracy -- but if : I understand correctly it anchors the UTC time to the standard, : and allows the UNIX seconds count (which often does not account for : new leap seconds, though some gmtime versions account for old ones) : to drift or jump whenever a leap second goes by. The problem is : then that interval calculations that include the leap second are off : by one second. That probably doesn't bother most people but is an : endless cause of hassle in scientific applications.
I think it would be wonderful to anchor our internal time to atomic time, even if our epoch isn't 1958. It's more important for our seconds to stay accurate than our timestamps, and we can make the approximate interfaces do the right thing if they know they're supposed to be approximate. The only problem is that we don't actually have atomic time available to most of our computers right now. Eventually we will, and I think it would be wonderful if were ready for that transition when it happens. Maybe even to the extent of pretending to be TAI-based by default even if we're not yet. We'll be wrong part of the time regardless of which way we pick. <rant> But I really, really wish UTC hadn't decided to add a leap second this year. It really wouldn't have hurt many folks to let midnight drift a few seconds and then do a major seconds correction at the end of the century, say. And it would have solved a lot of other problems. Oh well... </rant> : So, er, I guess I'm arguing that time/date stamps, if kept in numeric : counting-ticks form, should follow TAI in some easily definable way, : which probably means keeping track of leap seconds in a table that : can be updated easily. Even if the only interface most people use : is through UTC or civil time via the equivalent of gmtime (), IWBNI : the underlying engines knew enough to work well for those people : who do care about representing time at such high precision that leap : seconds matter. If the code is implemented with enough care to do : that right, then the natural epoch to use is probably 1958, though : as you pointed out the epoch itself is much less important than the : decision about what kind of time to track. I agree. time(2000) - time(1958) should just be a TAI constant. (Actually, it's a constant in UTC as well--it's just the POSIXly view of time that must die eventually. Slewing the clock for leap seconds is Just Wrong, and someday we'll fix it. Let's design with the assumption it will be fixed someday.) Larry
