WFC: Year-2000 issue

[Steve Allen]

I should make it clear that I support the proposal by Arnold Rots.  If
consensus emerges rapidly, I would be happy to see it accompany the
Y2K fix.

The underlying principle for my position is that archival plate and
catalog data should be encodable as FITS HDUs without any modification
to their originally-recorded exposure date/time, and that the language
of the FITS standard should not impose assumptions on how that
date/time should be interpreted.

Arnold Rots wrote:
> In order to maintain forward and backward compatibility, I propose:
>
> 1. Use of the keyword TIMESYS is strongly encouraged.  It will set the
>    time system for all time related keywords and data in the HDU.
>    Officially allowed values are: UTC, TAI, ET, TT, TDT, TCG, TDB, TCB.

I agree completely, but might wish that the last sentence was worded
"Initially, the officially allowed..."  in the expectation that our
current understanding of time systems is not yet complete.

When TIMESYS is not specified we are left with the current ambiguous
situation.  This is good because it permits FITS encoding of archival
plate data which did not have any of these official time systems.  In
those cases the DATE-OBS string can use the originally recorded
exposure time without modification.

> 2. The preferred value is "TT" which is considered equivalent to "TDT"
>    and "ET", though "ET" should not be used for data taken after 1976.

I agree.
This makes sense for ground-based observations under the presumption
that a linear time scale is best.  But the likelihood that most
ground-based observatories will actually use it seems small.

> 3. If the TIMESYS keyword is absent or has an unrecognized value,
>    a value of "UTC" will be assumed.

I would have to add "for dates starting in 1972".

The situation for most pre-1972 data should remain ambiguous as it now is.
I do not think it is a good idea to specify how software should try to
interpret pre-1972 dates.

> 4. The use of the "Z" qualifier in DATE-OBS is discouraged: if the
>    keyword TIMESYS is missing, it is implied; if TIMESYS is present and
>    has a value other than "UTC", this constitutes an inconsistency.

Yes.

> The following is not strictly needed for the present issue, but could
> be thrown in, if people think it's useful:
>
> 5. All days will be considered to have 86400 seconds, for the purpose
>    of conversions between days and seconds (i.e., a time interval in
>    seconds may not reflect elapsed seconds in UTC).

As currently stated I am not certain what is meant here by "days" and
"seconds".  What is the intent of this provision?

When consensus is reached, what kind of motion need be made so that
the WFC can take action?

--
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
sla at ucolick.org      Voice: +1 408 459 3046     http://www.ucolick.org/~sla
"You should know better than to trust a strange computer." -- C-3PO to R2-D2