Add DATE-OBS as optional keyword

[kelle]

I noticed that DATE-OBS is not in the table of metadata fields in Spectrum DM v1.2. There is TMID in MJD but no keyword for the date of the observation. I propose that DATE-OBS be added. Maybe as Char.TimeAxis.Coverage.Bounds.Start since it's supposed to be the date at the start of the observation.

(Follow up from convo started on Slack.)

[mcdittmar]

@kelle

I'm taking a look at the open issues on Spectrum to see what can/should be done next.
I did a little digging on this one to see how it fit into the Spectrum specification. Unfortunately, I can't refer back to our Slack conversation on IVOA as it is too old (90 day cap).

Char.TimeAxis.Coverage.Bounds.Start/Stop

• the model sets the TSTART/TSTOP keyword for these concepts.
• it looks like DATE-OBS/END could simply be considered alternative representations of the same concept, which would be a simple update, but I'd want to be sure there was no definition ambiguity as these are either standard or common keys.
• I took a quick look at the FITS-4.0 standard document, and it seems to have:
  • DATE-BEG = MJD-BEG = TSTART == different representations of the datetime value for “Start date/time of observation”
  • DATE-END = MJD-END = TSTOP == different representations of the datetime value for “End date/time of observation”
  • DATE-OBS — originally was not specifically defined as the ‘start’, and has been used for other (mid) times.. so defers to DATE-BEG for ‘start’ concept.

Mark

[aragilar]

Where possible I've been pushing people to use MJD-* because it's the least ambiguous of the standard date/time headers.

[mcdittmar]

From DM list: http://mail.ivoa.net/pipermail/dm/2025-February/006570.html

Markus D. writes:
You have my vote. Not so sure about the "Start of observation",
though; in SIAP, the corresponding metadata field is for the
midpoint, because that's in some sense more robust. So, before
issuing an erratum, I'd say we should first try to research whether
all the various FITS conventions agree DATE-OBS is the start of the
observation. Oh, and let's be modern and insist on DALI-style
timestamps in there.

[SebastienDerriere]

When you query image services for photographic plates (DSS survey), you get FITS headers with DATE-OBS corresponding to the mid-exposure date/time. This can be checked with asteroids moving in the image during exposure: the DATE-OBS value corresponds to ephemerids coordinates in the middle of the asteroid streak.
Be careful that sometimes the description says "Date and time at the start of the observation" - which is clearly wrong.

[kelle]

Basically, I want a (human-readable) header keyword that has the DALI-style date in it: YYYY-MM-DD['T'hh:mm:ss[.SSS]].

Since there's already TSTART/TSTOP (in MJD), I don't think we need to add a duplicative keyword.

My vote is to give DATE-OBS as an optional keyword which honestly, could be ambiguous about which date it corresponds to (Start/Stop/Local Date/UT Date, etc). Recommend the format be YYYY-MM-DD. If time is that important to the observation, they should defer to the MJD times in TSTART/TSTOP.

If that ambiguity is not acceptable for a data model, then my 2nd choice would be DATE-BEG in YYYY-MM-DD.

[kelle]

What else needs to be done in order to make progress on this suggestion? (As a reminder, my goal is to have an optional date/time keyword that expects DALI-style.)

I am comfortable with DATE-OBS and leaving it ambiguous but I'm also fine with using DATE-BEG/END.

[tepickering]

it should be noted for the record that there is an international standard for date/time format: https://www.iso.org/iso-8601-date-and-time-format.html. it is both human-readable ("DALI" style) and widely supported across many domains, including the FITS standard for DATE and DATE-OBS keywords. the FITS standard does not specify if DATE-OBS is the beginning, middle, or end of an observation. there's also the case where a spectrum is a combination of multiple spectra taken at different times so a single DATE-OBS doesn't make a lot of sense.