> > [...] But so what? It'll report 00:00:03 Monday when it's "really" > 23:59:57 Sunday --- why is this small number of seconds any more > important than any other small number of seconds error? [...] >
A miss is as good as a mile when a timestamp is an index into a hash table. There are many complex systems in this world that do a lot of wierd things with timestamps. These systems don't care whether the event really did happen at 12:34:56pm nor whether the clock was a few minutes slow that day. But they DO care that they are talking about the SAME event!!! Imagine a complex business environment represented by a large block diagram. Data, including fields that contain timestamps, propagate around this block diagram - We can't have timestamps gaining or loosing one second because they happen to pass through a block that represented a system where the leap second table was out of date - BECAUSE that timestamp may be an identifier. The fact that the timestamp was MINUTES wrong at the time it was created is entirely irrelevant. It must still stay the same no matter what conversion functions are applied to it. This is the very useful properly that Posix time currently has. This property is FAR more useful than caesium clocks, GPS, or any pico-second time syncronization technology anyone has ever thought of. -paul On Mon, 2011-02-21 at 01:26 +0000, Ian Batten wrote: > On 19 Feb 2011, at 23:57, Paul Sheer wrote: > > > > It is not only about being soooo isolated, but also about not being > > able to download the leap second table for any reason whatsoever. > > Suppose the leapseconds were guaranteed to be announced 12 months in > advance. Anything that can't perform an update, either manually or > automatically, for that period but which also expects to maintain a > clock to a precision better than 1s/18mo is hard to imagine. Do you > have a case in mind? > > > > > The conversion from 1298159105 to and from "2011-02-19 23:45:05" on > > Posix is currently not inclusive of leap seconds: you just do division > > by 86400. > > > > And you can do that without leapseconds to a precision of 1s/18mo, > which aside from bizarre fantasies of machines hooked to > Caesium/Rubidium clocks but unable to perform one bit/18mo of I/O to > the outside world is better than the precision of the clocks anyway. > > > A proper api includes leap seconds. hence the conversion depends on > > what's in your leap second table. "2011-02-19 23:45:05" is really > > 1298159129 in the Olson library. > > > > So what? If you ignore leap seconds in your isolated/cut-off example, > one consequence will be that an increasing window of seconds > immediately before midnight UTC will be "wrongly" reported as being in > the following day, because the local clock will have gained against > UTC. But so what? It'll report 00:00:03 Monday when it's "really" > 23:59:57 Sunday --- why is this small number of seconds any more > important than any other small number of seconds error? I'm still not > grasping the use-case for a precision clock that doesn't do I/O with > the outside world. > > > > The unix world is replete with software that converts both to and > > from ascii timestamps. > > > > for example, the conversion function should *behave* *consistently* > > regardless of your network suddenly becoming unplugged and your not > > being able to get the latest leap second table. > > It can't do that and also tick any timescale which is related to solar > time. > > ian > > _______________________________________________ > LEAPSECS mailing list > LEAPSECS@leapsecond.com > http://six.pairlist.net/mailman/listinfo/leapsecs > _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
