Year2000

[Arnold Rots]

Thanks for all your comments.  Below I am proposing a set of
changes and then go through all the substantive comments (i.e.,
the ones that request a change or an answer) and reference the
changes.

Please comment.

  - Arnold

--------------------------------%<----------------------------------------

Proposed changes to the DATExxxx proposal,
version dated 1997-06-25

1997-06-26

1. Insert the following sentence at the beginning of section 1:
"Although this document explicitly addresses the definition of
the DATE-OBS keyword, common sense dictates that the same rules
govern the format of other DATExxxx keywords that have come into
use over the years."

2. Replace in section 3.2:
"'T' is the time designator."
by:
"The literal 'T' is the ISO 8601 time designator."

3. Replace in section 3.2:
"The decimal point character is an ASCII full-stop."
by:
"The decimal point character is an ASCII full-stop (decimal value 46)."

--------------------------------%<----------------------------------------

Barry M. Schlesinger writes:

> Is the term "ASCII full-stop" universally understood?  Perhaps it 
> would be useful to give the hexadecimal representation as well.

This is addressed by change #3.

> In 4.4, which addresses the problems of files that mix time scales ... 
> How does one determine or define which time system is dominant in the 
> HDU?

This is a tricky issue and we hesitate to spell out any rules.
As an example, take a binary table that has a TIME column in UTC
and a BARYTIME column in TDB.  The dominant system would be UTC.
However, if TIME were relabeled UTC and BARYTIME relabeled TIME,
then TDB should probably be considered dominant.
It is easy to come up with a rule and then present examples that
would make the rule seem impractical.
I would suggest the following guidelines:
a. Use common sense.
b. If there is even the slightest chance of confusion, use comment fields.
Following a convention, such as the one suggested in the Appendix
(TIMESYS) is a way to remove any ambiguity but we wanted to keep
explicit reference out of the proposal-proper.

> Also, 4) has the title "Use of the DATE-OBS keyword" but addresses 
> usage of other DATExxxx keywords in 4.3 and 4.4.  In the original 
> proposal, it addressed only DATE-OBS.  So the title is somewhat 
> inconsistent with the content.

This is addressed by change #1.


William Lupton writes:

> When I read this, I was not certain whether 'T' was a literal 'T' or stood
> for a variable "time designator". I think the use of the phrase "additional
> terminator/separator (such as T)" added to my confusion.

This is addressed by change #2.
The slightly wordy formulation came about because ISO 8601 recognizes
more terminator/separators than just 'T'.


William Pence writes:

> >                           6) Transition
> >  
> > FITS readers must continue to interpret the old format, as a twentieth
> > century date, forever.  Readers should be altered as soon as possible
> > to cope with the new format.  In order to give adequate time for the
> > major package writers to revise their software, FITS writers should commence
> > writing the new format between 1998-01-01T00:00:00 and 2000-01-01T00:00:00.
> 
> It would be less ambiguous if the last sentence were changed to
> something similar to:
> 
> "In order to give adequate time for the major package writers to revise
> their software, FITS writers should commence writing the new format as
> soon as possible after (but not before) 1998-01-01T00:00:00."

I am puzzled here.  The text of the proposal is quite specific,
whereas the suggested change does not does not acknowledge that
the change-over needs to occur before 2000-01-01.  As to the
asap wording, common sense dictates that anyway and it should
be understood, but I don't think it is appropriate in the formal
proposal text.

> The HEASARC has a large archive of FITS files containing the TIMESYS
> keyword with other values, such as  'MJD', or '1980.0'.  I would like
> to be reassured that the current proposal does not invalidate the past
> and continued use of the TIMESYS keyword in this way by the HEASARC.  I
> would assume that this is the case since this Appendix is not part of
> the formal agreement.

This is also taken care of by 7.4, since all those files use UTC.