WFC: Year-2000 issue

[Arnold Rots]

I agree with Steve, in turn.  Comments:

"Initially, the officially allowed...": sounds good to me.

"for dates starting in 1972": same.

I like the pre-1972 ambiguity (;-).

On the  "days" and "seconds" issue:
It means that if you TIMESYS is UTC, and your time is kept in seconds
since a reference date, leap seconds are removed from those time values,
so that dividing time by 86400 gives you the elapsed time in UTC days.
This obviously gets you in trouble at the leap seconds, but you are
going to have an ambiguity problem, no matter what; so, one might as
well define when and where the ambiguity is going to be.
But, as I said, I don't feel particularly strongly about it, except to
say that we do need a convention, here.

  - Arnold Rots

> 
> 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
>