WFC: Year-2000 issue (again)

[Arnold Rots]

Don,

We're all astronomers, aren't we?  Or at least working in an
astronomical environment.  That means that we should know
something about time and time systems; hence, a TIMESYS keyword
should not throw us in total confusion, as it would, say, a
freshmen sociology student.

There are a number of arguments against the obligatory use of UTC:

1. Before 1972, UTC is not defined.

2. This convention is supposed to be blessed by the IAU; the IAU's
"official" time system is TT.

3. Not all FITS files use UTC (nor TT) for the time values they
contain: things like (M)JDs, TIME columns, etc.  Requiring the
use of UTC for DATEXXXX keywords would mean that these files (or,
rather, the HDUs) would be internally inconsistent: some time
values would then be in UTC, while other might be in TT, TDB, ...
This, in my opinion would be a far worse confusion.

4. Applications that need to be extremely careful about time
issues, ought to know about different time systems.  Applications
that don't, well, they probably are not interested in very accurate
times and for those it shouldn't matter whether they mistakenly
interpret DATEXXXX as being in UTC.

Finally on the issue of the Z qualifier: if the time system is not
UTC, use of the Z qualifier would cause a contradiction; if the
time system _is_ UTC (or the keyword is absent, and UTC is assumed,
for post-1972 data), it is not needed.  Hence the abolition of the
Z qualifier.

Something tells me that this may not have convinced you, but did
it at least succeed in making the proposal more palatable?

Cheers,

  - Arnold

> 
> Dear WGAS FITS Committee members,
> 
> I am an ex-officio (and non-voting) participant in WFC discussions.  I
> am not speaking as Chair of the IAU FITS Working Group here: the remarks
> below are my personal opinions.
> 
> "AR" == Arnold Rots <arots at xebec.gsfc.nasa.gov> writes:
> AR> [re Bunclark] proposal for how to revise the definition of the
> AR> DATExxxx keywords to provide a 4-digit year..
> AR> .. proposed amendments..
> AR> 1. Use of the keyword TIMESYS is strongly encouraged.  ..
> AR> 2. The preferred value is "TT" which is considered equivalent to "TDT"
> AR>    and "ET", though "ET" should not be used for data taken after 1976.
> AR> 3. If the TIMESYS keyword is absent or has an unrecognized value,
> AR>    a value of "UTC" will be assumed for dates starting in 1972.
> 
> This proposed change to the Bunclark DATExxxx proposal would create
> unnecessary confusion about dates and time in FITS datasets passing in
> interchange.  This confusion would be risky for our community because it
> could result in improper calculations and might thereby compromise
> astronomy research which depends on combining datasets from multiple
> datasystems.
> 
> Our interchange format design will be more robust if we revise the
> Bunclark proposal to specify that the DATExxxx timescale is (only) UTC.
> 
> The confusion of multiple timescales is unnecessary in interchange
> because conversions between UTC and other modern uniform timescales are
> well defined (e.g., SLALIB routines SLA_GMST(), SLA_DAT() and
> SLA_DTT()). FITS reading and writing software can transform UTC to and
> from local timescale conventions with no ambiguity or loss of precision.
> 
> In summary, I recommend that the WFC agree on a single timescale for
> DATExxxx interchange purposes (UTC is the obvious choice) and that the
> TIMESYS keyword be deleted from the proposal that WFC forwards to the
> IAU-FWG for further consideration.
> 
> AR> 4. The use of the "Z" qualifier in DATE-OBS is discouraged..
> 
> I recommend that WFC modify the Bunclark proposal so that it either
> _requires_ the appended 'Z' (to explicitly indicate the UTC convention)
> or else _forbids_ the 'Z' (because the UTC convention is implicit). It
> doesn't matter which option is chosen, the important thing is that the
> unnecessary option should be removed from our interchange format design.
> 
> AR> The default interpretation of all DATExxxx keywords shall use the
> AR> Gregorian Calendar.
> 
> Yes.
> 
> Regards,
> Don
> -- 
>   Donald C. Wells         Associate Scientist         dwells at nrao.edu
>                     http://fits.cv.nrao.edu/~dwells
>   National Radio Astronomy Observatory                +1-804-296-0277
>   520 Edgemont Road,   Charlottesville, Virginia       22903-2475 USA
>