An immodest proposal

[Rob Seaman]

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