[LEAPSECS] ISO TC 37

[Rob Seaman]

Tom Van Baak wrote:


> I would like at some point, regardless of how the ITU vote turns out for this list to collectively work toward external education rather than internal bickering or google baiting.


My reply from last Friday still seems appropriate (appended).  We're also pretty proud of:

	http://www.univelt.com/book=3042

with preprints and presentations online at http://futureofutc.org - a truly excellent meeting and a foundation for whatever comes next.  The round table discussions were particularly a highlight of this meeting and excellent transcriptions (thanks to John Seago) are available on the preprints page and following each paper in the proceedings volume.

The discussions on leapsecs, though understandably perhaps a bit more exasperating for everybody recently, are almost always on topic and the mailing list is remarkably free from noise compared to other mailing lists I've read or participated in.  That consensus has yet to be reached internal to the list is mostly a function of the external politics.  We have made progress on several fronts such as the desirability for extending the scheduling horizon for leap seconds.  The ITU process has not even attempted to reach consensus.


> For every one of us there are a thousand engineers out there who are clueless about the subtleties of timescales. We could all work together on a best practices document.


I guess the notion is a cookbook for various programming environments or in support of NTP networks, GPS clocks, atomic dohickeys, etc?  Surely you aren't worrying about the various astronomical community documents that would have to be developed :-)

While such a document or documents could be useful (independently of redefining UTC), it is not going to be a small effort, rapidly concluded.  There would be a large amount of precisely that consensus-building work before such documents/volumes could be written, and it would have to be a collaboration in some fashion with those engineers and other stakeholders.

We could make a start by suggesting a bookshelf of references.  In addition to the futureofutc.org proceedings (IMHO), essentials are:

	http://www.wiley.com/WileyCDA/WileyTitle/productCd-3527407804.html
	http://www.crcpress.com/product/isbn/9781439814635

Other suggestions?


> In particular, it seems to me many of your telescope concerns would be non-issues if you could use your influence to push the use of UT1/DUT1 in those systems related to pointing.


Pointing is only one of many issues:

	http://www.cacr.caltech.edu/futureofutc/preprints/36_AAS_11-677_Seaman.pdf

I already addressed the over-simplification of the UT1/DUT1 issue below.

Rob
--

Begin forwarded message:


> From: Rob Seaman <seaman at noao.edu>

> Subject: Re: [LEAPSECS] The Economist

> Date: January 13, 2012 10:13:49 AM MST

> To: Leap Second Discussion List <leapsecs at leapsecond.com>

> Reply-To: Leap Second Discussion List <leapsecs at leapsecond.com>

> 

> Hi Tom,

> 

>>> Just none of them have ever been on the table in ITU-R WP7A.)

>>> Rob

>> 

>> Yeah, given the wording, it will be amazing to me if the resolution passes.

> 

> I'd say the risk of passage is quite significant.  And "risk" is a carefully chosen word.

> 

>> Can you switch gears and use your energy be a focal point within the astronomical community

> 

> You mean as in (twelve years and one month ago today):

> 

> 	http://listmgr.cv.nrao.edu/pipermail/fitsbits/1999-December/thread.html#949

> 

> Or the well-attended session at the Astronomical Data Analysis Software and Systems XV meeting in 2005:

> 

> 	http://www.adass.org:8080/Conferences/2005/Venue/events/calendar/events/bof

> 

> Or the poster paper at ADASS XVI in 2006:

> 

> 	http://www.aspbooks.org/a/volumes/article_details/?paper_id=5388

> 

> that was announced on this mailing list:

> 

> 	http://www.ucolick.org/~sla/navyls/1164.html

> 

> (And a copy of which is on the wall behind me.)  I personally began chatting up the issue at ADASS X in 2000 and have raised it in many astronomical venues since.  Others like Steve have been doing the same, especially through his invaluable web site:

> 

> 	http://ucolick.org/~sla/leapsecs/

> 

> The talking points on leapsecs naturally focus on policies.  The talking points at technical meetings such as above focus on mitigating the effects of those policies.

> 

>> to actively promote the use of DUT1 as a floating point number?

> 

> Your general point was well-received in the discussions at the Exton meeting, for instance:

> 

> 	http://www.cacr.caltech.edu/futureofutc/preprints/27_AAS_11-672_discuss_5.pdf

> 

> (Floating-point is not a panacea, e.g., http://arxiv.org/abs/1007.1179 and references within.)

> 

>> That would solve two problems. One is that people (programmers, astronomers) could start using the high precision values that are freely available through VLBI/IERS instead of the ancient 0.1 second fixed point version found in print or in LF timecode broadcasts.

> 

> But the problem is far broader than just a more precise value for DUT1, e.g.:

> 

> 	http://hea-www.cfa.harvard.edu/~arots/TimeWCS/

> 	http://ivoa.net/Documents/latest/STC.html

> 	http://www.aspbooks.org/a/volumes/article_details/?paper_id=28994

> 

> Some of the many software issues with redefining a fundamental standard like UTC were touched on during the discussion that followed my presentation on impacts to the National Observatory's widely-used image processing suite:

> 

> 	http://www.cacr.caltech.edu/futureofutc/preprints/37_AAS_11-677_discuss_2.pdf

> 

> Redefining UTC - changing it from an angle to a duration timestamp - is not like tweaking the definition for the meter to be a little longer or the kilogram to be a little heavier.  Its entire meaning would change and this will have broadly rippling effects.

> 

>> The second problem that would solve is astronomical code would start to explicitly use UT1 for precise angle instead of making assumptions about how close or far UTC is from true angle. When someone uses UT1 they tie their desired angle precision to the resolution of DUT1 that they fetch (i.e., the number of decimal places).

> 

> Precision is not the only parameter.  UTC has rather always provided an accurate value, also precise to better than 1 second.  Many applications require exactly that and it would be poor engineering to build in added complexity by specifying that systems and interfaces community-wide must include DUT1.

> 

>> This tie is not possible with UTC since the angle precision is not explicit in any UTC time stamp.

> 

> I certainly hope that the current situation will lead to building better standards and infrastructure for timekeeping.  Pretending that time-of-day is atomic time is not a fruitful way to start.  They are two different things and the systems we build should model them that way:

> 

> 	"Make everything as simple as possible, but not simpler" - Einstein

> 

> That still leaves plenty of room for more nuanced evolution of the standards than we've seen so far.

> 

> I've got a couple of colloquia over the next few months and will present on this topic at astronomy's biennial engineering meeting (http://spie.org/as107/).  Advice would be welcome on additional ways to continue to be a focal point on the issue.  Not doing so doesn't appear to be an option.

> 

> Rob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20120118/10aa2426/attachment.html>