WFC: Year 2000 issue

[Barry M. Schlesinger]

Various comments on the previous discussion

PT = Peter Teuben
EFC = European FITS Committee
SA = Steve Allen
PG = Preben Grosbol

PT> Personally I like the proposal. It does violate the rule that
PT> only the first 8 characters of a string be relevant to interpreting the
PT> data, but we should be able to live with that rather old-fashioned rule.

The strongest statement of this rule is in the NOST standard, section 
5.3.2.1, referring to character string values

"Reading the data values in a FITS file should not require decoding 
any more than the first eight characters of a character string value 
of a keyword."

The rule means that all the information needed by the software to read 
the tape must be in the first eight characters; it does not refer to 
information needed only for the scientific interpretation of the data.
The User's Guide recommends that essential information all be in the
first eight characters but does not require it. 

EFC>     The European FITS Committee suggests
EFC>
EFC>        1) that the use of UTC time scale is made mandatory for all
EFC>          DATExxxx keywords including DATE-OBS both for date and
EFC>          date/time representations (i.e. 'ccyy-mm-dd' and
EFC>          'ccyy-mm-ddThh:mm:ss[.sss...]Z' formats),

EFC>       2) that the Appendix should not be a part of the proposal
EFC>          but only appended for information.

EFC> ... minor technical changes and clarifications may be
EFC>     implemented in this process....


SA> I am concerned that mandating UTC may prove too restrictive.  Whenever
SA> pre-1972 (pre-UTC) data are encoded as FITS this European mandate
SA> would force a dilemma on FITS writers and an ambiguity on FITS readers
SA> who want to specify accurate time.  The Bunclark proposal denotes UTC
SA> as "preferred", and permits it to be specified explicitly by use of
SA> the 'Z' suffix.  This seems quite adequate for solving the FITS Y2K
SA> problem before Y2K happens.

The European FITS Committee would at the least need to specify what is 
to be done for dates before 1972 if UTC is mandated.

SA> It does not make sense to mandate that the time be UTC without also
SA> mandating that the calendar date be expressed in the Gregorian
SA> calendar.  There is currently no FITS specification of the calendar
SA> system....

SA> ... I believe that the specification of a time system should not
SA> precede the specification of a calendar system.  These are items which
SA> should be "preferred" and not "mandatory" for the initial adoption of
SA> the Bunclark proposal.  

PG> On the Calender issue, ISO 8601 (and therefore the proposal) clearly
PG> specifies the Gregorian calender (see section 3.8)....
PG> In the European discussion a
PG> main argument for the suggestion was that "preferred" in reality
PG> means that the time system is undefined since you can not assume
PG> any by default.  The ISO 8601 format does not either allow for
PG> a 'Z' after the date to specify UTC.


SA> In order to see that section one would have to purchase ISO 8601.  It
SA> is good for FITS to acknowledge the source of the date format
SA> specification, but it is not good to require its purchase for the
SA> correct interpretation of FITS.  

We already require IEEE-754 floating point, which requires purchase.

SA> Any Gregorian calendar mandate must
SA> be explicit in the text of the Y2K amendment.

The European FITS Committee is suggesting that the Appendix (ISO 8601)
not be part of the proposal.  If so, purchase is not necessary.
However, if the Appendix is not a part of the proposal, then the
calendar is not formally specified.  

SA> Still, I do not believe that either Gregorian or the UTC should be
SA> mandatory in the Y2K proposal....  

SA> The original Bunclark proposal adequately solves the immediate Y2K
SA> problem and should be adopted without significant [changes?].  
SA> The status quo of
SA> other temporal ambiguity issues should remain and be considered
SA> separately in order not to jeopardize the urgently needed fix to FITS.

Whether a consensus can be reached quickly should be an important 
criterion on whether or not to consider other issues. I think that 
questions such as TIMESYS are worth discussing until we either reach a 
rapid consensus or realize that none is emerging quickly. 

				Barry Schlesinger