[LEAPSECS] The Economist
seaman at noao.edu
Fri Jan 13 12:13:49 EST 2012
>> Just none of them have ever been on the table in ITU-R WP7A.)
> 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):
Or the well-attended session at the Astronomical Data Analysis Software and Systems XV meeting in 2005:
Or the poster paper at ADASS XVI in 2006:
that was announced on this mailing list:
(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:
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:
(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.:
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:
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.
More information about the LEAPSECS