[time-nuts] FW: Bulletin C number 30
cfmd at bredband.net
Tue Jul 5 12:11:06 EDT 2005
From: "M. Warner Losh" <imp at bsdimp.com>
Subject: Re: [time-nuts] FW: Bulletin C number 30
Date: Tue, 05 Jul 2005 09:44:46 -0600 (MDT)
Message-ID: <20050705.094446.31252443.imp at bsdimp.com>
> : Instead of using TAI, which doesn't have leap
> : seconds, you chose to use UTC, which does.
> You would be wrong there. We *DO* use TAI for our internal time
> keeping. The trouble with that is two fold. One: GPS receivers tend[*]
> to give you time in UTC and you need to convert the one to the other.
> Second: Users want to see the UTC time on their atomic clocks, time
> code counters, etc. So you're stuck displaying UTC. Both of these
> are reasons for needing to know the leap seconds involved. And No,
> the users aren't interested in TAI time, so displaying it instead is
> not an alternative.
> Internally, all the software I've written uses time scales without
> leap seconds. However, that doesn't get away from any problem except
> the 't1 - t2' problem you have in utc.
The main problem is that you can't directly get the UTC - TAI difference,
right? If you had that, then you could always convert between them. There is
however a peculiarity of which I am sure you are aware of, you would still
need to know when the leap-seconds occured when doing time-differances over
possible leap-second insertion points. TAI(t2) - TAI(t1) may not be equalent
to UTC(t2) - UTC(t1).
Video synchronisation is going UTC, but I pointed out that all sampling rates
etc. is actually following TAI and not UTC. At least they chose to coordinate
them when TAI = UTC which is a good start. They failed to identify the time-
zone in which they where coordinated, which is another story, so their trial
publication of the standard got one comment and they had to re-write those
parts since they where plain wrong. Ah well. I still wonder if they finally got
it all correct, since my attention was diverted away from it.
More information about the time-nuts