WFC: Year-2000 issue

[Arnold Rots]

I have concerns similar to Steve's, though with a different twist.

In my experience, the use of DATE-OBS and similar keywords has been
more for purposes of readibility (to the user) than for serious
timing work.  The idea being that if you want to do something serious,
you use (M)JDs, but it's nice for the user to be able to relate a
JD to his/her daily life.

I think it would be terrible if DATE-OBS would use a time system
different from, say, MJDREF in the same file.  So, some discussion
of this issue is appropriate, here.

Even when using JD-based times, large parts of the community have
been very slack in their definitions.  In most cases, UTC or TAI has
been used, but it is often not documented.  (Some people appear to be
under the mistaken impression that the use of (M)JD implies a
particular time system: not so.)

The way we have chosen to get out of this uncertain situation for
XTE (where the "T" stands for "Timing"), is by requiring a keyword
TIMESYS which could have any of the following (string) values:
UTC, TAI, ET, TT, TDT, TCG, TDB, TCB; undoubtedly there are more,
but I would hesitate to use UT1 or any local times.

Considering that we are working on an IAU standard, it would seem
appropriate to make the IAU's preferred time system also the preferred
one for FITS files: TT (which, in some way is equivalent to ET and TDT).

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.

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.

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

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.

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


  - Arnold Rots

> 
> teuben at astro.umd.edu wrote:
> 
> >      The European FITS Committee suggests
> >
> >        1) that the use of UTC time scale is made mandatory for all
> >           DATExxxx keywords including DATE-OBS both for date and
> >           date/time representations (i.e. 'ccyy-mm-dd' and
> >           'ccyy-mm-ddThh:mm:ss[.sss...]Z' formats),
> 
> I am concerned that mandating UTC may prove too restrictive.  Whenever
> pre-1972 (pre-UTC) data are encoded as FITS this European mandate
> would force a dilemma on FITS writers and an ambiguity on FITS readers
> who want to specify accurate time.  The Bunclark proposal denotes UTC
> as "preferred", and permits it to be specified explicitly by use of
> the 'Z' suffix.  This seems quite adequate for solving the FITS Y2K
> problem before Y2K happens.
> 
> It does not make sense to mandate that the time be UTC without also
> mandating that the calendar date be expressed in the Gregorian
> calendar.  There is currently no FITS specification of the calendar
> system.  UTC and TAI are often expressed in counts of seconds and MJD
> counts of 86400 seconds; if there is any specification for the use of
> Gregorian calendar for either timescale it is not widely enough known
> that it can be presumed.
> 
> In short, I believe that the specification of a time system should not
> precede the specification of a calendar system.  These are items which
> should be "preferred" and not "mandatory" for the initial adoption of
> the Bunclark proposal.  They can be resolved at a later date when
> other time system issues are considered.
> 
> --
> 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
>