Jonathan Swift circulated a "Modest Proposal" that he did not intend
to see actually carried out. Here is a pragmatic timekeeping
proposal that should be straightforward to carry through to a
demonstration phase. In addition, none of the various leap second
factions will be required to eat their own children.
I'm copying David Mills to serve as ground truth on NTP - don't know
if he is already on the leapsecs mailing list. The NTP community
seems quite busy lately - sorry to add to that.
Proposal first, discussion after:
1) TAI can be recovered from UTC given a table of DTAI.
2) NTP can convey TAI as simply as UTC.
3) Deploy a small network of NTP servers to keep TAI, not UTC.
4) NTP client machines could therefore trivially select between TAI
and UTC by subscribing to different servers.
5) This would provide an unbiased experimental sandbox for civil
timekeeping issues.
Discussion:
1) UTC already provides a practical realization of TAI for civil
timekeeping purposes. Some precision timekeeping users might find
this method of transport unacceptable for their purposes - but these
are users who would already be drinking straight from the TAI cow,
and NTP itself is likely inappropriate for their purposes anyway. If
and when a more direct source of TAI becomes available, this retro-
conversion step would no longer be needed.
2) and 3) Suspect it isn't quite as simple when technical details
are folded in for various platforms - but if NTP has trouble
conveying TAI, we really ought to know about it now :-) From http://
tf.nist.gov/general/pdf/1383.pdf, we learn that "all [ITS] servers
provide [...] UTC(NIST)", but this is a question of policy, not
technology. If we jigger a few stratum 0 servers to mimic TAI,
stratum 1 and 2 will follow along like sheep following gay cowboys.
Would think that between the various readers of leapsecs we could
identify sufficient hardware to deploy an initial prototype TAI/NTP
network. Googling TAI and NTP shows that this in not a new idea -
it's worth revisiting. At any rate, the fundamental proposal is to
commission an experimental TAI testbed - how to achieve this is a
matter we can debate.
4) NTP has a requirement to provide access to civil time standard
(s). If civil time evolves to allow both TAI and UTC (or
derivatives), NTP should evolve to more easily support multiple time-
scales. Convenience and security features would likely be needed to
establish a higher level of robustness against the risk of mistaking
one time-scale for the other. Comparing relative levels of risk is a
key objective of the proposal you are reading.
5) I know some folks are tired of my rhetorical flights. (Sorry,
couldn't restrain myself with the sheep remark, above :-) But no
more so than others, including myself, are tired of the casual
dismissal of the importance of mean solar time. No need to belabor
any earlier arguments. With easy access to realizations of both
interval time and solar time, TAI and UTC, we would be able to pursue
the development and testing of coherent prototypes of all types of
proposed timekeeping infrastructure. A key issue with timekeeping is
interoperability - here is a way to test and validate it.
For instance? Well - we all pretty much loathe Posix timekeeping.
How about relayering it internally on TAI? A separate presentation
layer would recover UTC using DTAI. Would this work? I don't know -
but here is a way to find out.
Or? Well - a central assertion supporting the leap hour proposal is
that civilians don't care about the position of the sun in the sky.
I won't repeat my screed about the distinction between secular and
periodic effects - but we could devise ways to test this assertion
and to characterize acceptable excursions from UT by introducing
large offsets into the DTAI correction. What happens to a flight
simulator fed TAI as DTAI grows? We know that telescope control and
astronomical data reduction software will break - exactly how and in
what modules? Can we uncover other implicit dependencies of civil
time on solar time? I'm willing to see this put to the test. How
about you?
(This is similar to what I did prior to Y2K to provide a testbed for
remediation of our algorithms and data structures. My Solaris
desktop was set forward by 11 years from the period of around
mid-1998 until mid-2000. The point being that 2009 will use the same
calendar as 1998, etc.)
Surely we can come up with many other interesting timekeeping issues
and technologies to test directly. This has got to be a more
productive way to spend our time than debating sketchy proposals. I
suspect we can all agree that a regime of prototyping and testing can
only help if any of the proposals for new timekeeping standards or
timekeeping infrastructure is to succeed in the real world.
Rob Seaman
National Optical Astronomy Observatory
Received on Mon Feb 06 2006 - 09:40:50 PST
This archive was generated by hypermail 2.3.0
: Sat Sep 04 2010 - 09:44:55 PDT