Use FITS-4 compliant date keywords in resulting maps

[wtbarnes]

The FITS-4 standard defines the following keys to specify the date(s) of the observations,

See Table 35 of this document.

In the resulting maps from fitting EIS spectra, the metadata have the keys DATE_BEG, DATE_END, DATE_AVG to describe the beginning, end, and average time of the observing interval, respectively. Note that these use a "_" character rather than the standard "-". In the EISMap source this is accounted for by overriding the relevant properties on the map itself. However, this seems like fixing a mistake that we can account for by just fixing the keys before producing the maps themselves by just replacing the relevant keys.

[MJWeberg]

Excellent point! I agree that following the standard is generally best. Unfortunately, however, this would break the convention that all other EIS keywords use "_" instead of "-" to delimit words in header keys. Of particular note, both DATE_OBS and DATE_END are officially specified and used by all Hinode instruments. I have no idea why they decided to use this convention other than "many instrument teams seem to view the FITS standard as merely a suggestion". As far as I can tell, DATE-OBS has been the FITS standard since v1.0 in the early 90's!

Since DATE_BEG and DATE_AVG are new keys that EISPAC is adding to the output headers, I think it would be reasonable to switch to the standard format. I could also see a strong argument for updating the other keys in the output files to ensure complete and full compliance with the FITS-4 standard (EIS-specific keys. such as STUDY_ID would be left unchanged). I will discuss this with the rest of the EIS team here and see what they think.

[MJWeberg]

Sorry for not following up earlier. The general consensus here is that it is important to maintain consistency with established, long-standing conventions. However, we also recognize that it is important to follow the official standards whenever possible. Therefore, the best solution we can come up with is to keep the existing keywords and add an extra set of keywords in the DATE-VVV format.

I know this violates the general principle of avoiding duplicate information, but it also least likely to cause confusion or break someone's code. Given this plan of standardized redundancy, I am also rethinking continuing to add DATE-BEG to the headers, since the FITS-4 standard already specifies that DATE-OBS should be assumed to be the start time unless explicitly stated overwise. However, again, removing keywords has the potential to break someone's code. Do you have any thoughts or insight on this, @wtbarnes?