Portable general timestamp format, not 2038-limited

Martin Gregorie martin at see.sig.for.address
Tue Jun 26 08:04:50 EDT 2007


Paul Rubin wrote:
> Martin Gregorie <martin at see.sig.for.address> writes:
>>>> pretend the leap seconds never happened, just as Java does.
>>> 	Which leaves you about 30 seconds out by now - smelly.
>> Easy solution: always read Zulu time directly from a recognized
>> real-time clock
> 
> That's no good, it doesn't let you accurately compute the difference
> between timestamps.
 >
I don't recall the OP mentioning time interval computability - just a 
requirement for sub second accuracy timestamps.

> If you want a precise timestamp and you don't
> want to deal with leap seconds, TAI is one approach.
 >
TAI? Care to provide a reference?

> There is
> currently some political pressure to get rid of leap seconds to ease
> computer synchronization, but (at least some of) the astronomy
> community is opposed; see
> 
Yes, that's just silly, especially because if you're trying to do 
date-time calculations across historic time or non-western calendars 
(e.g. Islamic) the minuscule accumulated leap second error is dwarfed by 
  all the other uncertainties.

> No do NOT use stratum 1 sources for something like this.
 >
Fair comment. I was thinking about network delays and jitter and should 
not have forgotten Stratum 1 congestion. Of course, you could always run 
your own local Stratum 1 clock if accuracy is that important.

IIRC the major American interbank networks use GPS as their time 
standard because its about the only system that can avoid jitter and 
propagation delays over continental areas without introducing smoothing 
  engines, e.g. ntpd.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |



More information about the Python-list mailing list