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