Re: [LEAPSECS] mining for data about time

From: NGS <Jim>
Date: Fri, 15 Aug 2003 08:23:28 -0400 (EDT)

Steve Allen wrote:
> These schemes are somewhat fragile. It would be interesting to know
> how often a format change in Series 7/Bulletin A has caused them to
> fail.

For this very reason, format changes in Bull. A are extremely rare. When
it has been necessary, the change was announced very far in advance. The
actual Bull. A itself -- in the narrative format -- is preserved for back
compatibility in those long-running systems that still rely on it. All
the same info is available in machine-readable, rigidly formatted data files
at <http://maia.usno.navy.mil/>. The same is true at the Paris Observatory.
For instance, all the GPS analysis groups that I know about, where the
reliance on accurate EOPs is far more sensitive than for telescope pointing,
crontab-scheduled daemons/processes automatically download the appropriate
files and parse them with high reliability. Nothing is ever absolutely
fail-safe nor infinitely robust, but the situation you portray may or may
not be fragile only because of decisions (or not) on the part of the
end-users. Those users who really depend on accurate EOPs will not have
failed to implement robust systems.

Basically the same situation exists for UTC offsets published by BIPM.
Regardless of how NIST or other groups may choose to redistribute the same
results, BIPM's Circular T (a narrative formatted document) is directly
accessible from <ftp://62.161.69.5/pub/tai/publication/> and the embedded
data for individual labs are avaiable as machine-readable data files at
the same ftp site.

> Shouldn't the astronomers, the atomic clock keepers, and the system
> designers alike be demanding that IERS (BIPM, USNO), NIST and other
> such agencies provide these data in more easily used formats?

While I would not say that there is no room for improvement, the situation
is in far, far less dire straits than you depict.

--Jim
Received on Fri Aug 15 2003 - 05:24:15 PDT

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:54 PDT