Portable general timestamp format, not 2038-limited

Martin Gregorie martin at see.sig.for.address
Mon Jun 25 13:36:33 EDT 2007


Steve O'Hara-Smith wrote:
> On Mon, 25 Jun 2007 11:17:27 GMT
> Roedy Green <see_website at mindprod.com.invalid> wrote:
> 
>> On Sun, 24 Jun 2007 18:14:08 -0700, rem642b at yahoo.com (Robert Maas,
>> see http://tinyurl.com/uh3t) wrote, quoted or indirectly quoted
>> someone who said :
>>
>>> - Stick to astronomical time, which is absolutely consistent but
>>>   which drifts from legal time?
>> depends what you are measuring. IF you are doing astronomy, your
>> advice would apply. If you are doing payrolls, you want effectively to
>> 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 and store the result in a database as a 
ccyymmddhhmmssfff ASCII string where fff is milliseconds). By 
"recognized real-time clock) that I mean an atomic clock and 
distribution network such as GPS or (in the UK or Germany) an MSF low 
frequency radio broadcast. NTP using tier-1 sources may do the job too. 
The clock interface may need to be JINI because most suitable receivers 
have serial interfaces.

This is certainly accurate for financial transactions: the UK CHAPS 
inter-bank network has a Rugby MSF receiver in each bank's gateway 
computer and uses that for all timestamps.






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



More information about the Python-list mailing list