[time-nuts] FW: Bulletin C number 30
imp at bsdimp.com
Tue Jul 5 13:05:28 EDT 2005
> At 11:44 AM 7/5/2005, M. Warner Losh wrote...
> >In message: <188.8.131.52.0.20050705100343.0412ac70 at mjs.alientech.net>
> >: No, you didn't. What you and Warner HAVE demonstrated is that you
> >: _chose_ the wrong time coordinate system for your
> >: systems/applications.
> >How do you know this? I've demonstrated no such thing. 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.
> If it's not one system, it's another. As I said, you (the collective
> you - your organization) _chose_ to use UTC. The need to maintain
> both UTC and TAI, and deal with leap seconds, is purely an issue
> internal to your organization. Perhaps your users have a real need
> for time closely correlated to UT/GMST, in which case stopping UTC
> leaps seconds would do them a disservice. You're trying to make UTC
> into something it isn't.
A number of things:
(1) I never said we should stop leap seconds. I said there's
a huge cost associated with them.
(2) UTC is an externally imposed requirement. Our users have
different needs for things, but UTC is a standard, and
we must provide it.
(3) It is called UT1 these days.
(4) Time is delivered from GPS as week number, second in
week. The GPS time scale isn't TAI, but yet another one
that is needed. While it also gives a GPS UTC offset in
its data stream, that can cause big delays in startup on
some GPS receivers while the almanac is downloaded.
Why do you refuse to accept the fundamental message I'm telling you,
based on my first hand experience:
Leap seconds have a huge cost associated with them, and they
insinuate themselves into many areas one might not naively
have thought of.
More information about the time-nuts