A discussion today highlighted a lack of clarity in this RFC: we are proposing to make the column name consistency adjustments in all DIA tables, including those for future DRP runs (as encapsulated in imsim.yaml). Otherwise the column name formats will remain inconsistent between DRP tables in future DRs, as they are in DP0.2.

Responding to a comment from Meredith Rawls on DM-37196 (the implementation ticket), since it's a topic for this RFC-906.

I am concerned about the change from midPointTai to midPointMjd. The former is a time scale, and the other is a time format. I recognize Gregory's assertion (both in an RFC comment and deep in a therein referenced Slack thread) that the times we report are in fact MJDs, but isn't it MJD in TAI?

The original RFC proposed midPointTime which I think is much less of an eyebrow-raising change, and also gives us the flexibility to gracefully specify exactly what flavor (scale + format) of time we are reporting in documentation rather than hardwiring it in column/schema names. I worry that calling it midPointMjd might cause a user to infer this is MJD in UTC (not TAI) and do their science wrong, since UTC is the astropy default.

Note this conversation on slack in February/March. The "MJD"ness is the important thing for users to be able to interpret this value (it's a double, not an SQL time). All of our reported times are TAI; MJD is not necessarily in TAI. We seem to have de-facto settled on MJD as our preferred time reporting format. As I said on that slack thread, I could be convinced to make that `midPointTime`, but we have expMidptMJD and obsStartMJD in the Visit and CcdVisit tables as precedent.

FWIW, Meredith Rawls brings up a good point...

E.g., in solar system community, observation times are commonly sent in UTC (e.g. see https://www.minorplanetcenter.net/iau/info/OpticalObs.html) and orbits are given in TT (e.g., see https://www.minorplanetcenter.net/iau/info/MPOrbitFormat.html). And our orbits table will also have the epoch given as MJD but in TT (as is convention).

Having TAI explicitly in the name of columns with time quantities would help with this class of mistakes – thinking TAI is UTC, or TT, etc. They're quite insidious to track down when they happen (we've had this bug with SDSS for about ~5 years until we noticed).

I've updated most of the double-based time fields to be explicitly MjdTai in their names, spelled out expressed as Modified Julian Date, International Atomic Time in the relevant docstrings, fixed the DiaSource.midPoint capitalization and changed Visit/CcdVisit expMidpt/expMidptMjdTai to match DiaSource as just midpoint:

raDecTai->raDecMjdTai

midPointMjd->midpointMjdTai

obsStartMJD->objStartMjdTai

expMidptMJD->midpointMjdTai

expMidpt->midpoint -- an SQL timestamp

See this sdm_schemas commit for the exact changes.

This leaves unchanged fields like SSObject.discoverySubmissionDate and SSObject.firstObservationDate which are currently unused. It also doesn't change MPCORB.epoch which comes straight from the MPC database schema and I think we have to keep it matching that (even though it's TT, not TAI).

Do we need to have duplicates of the old names of these columns in imsim.yaml/hsc.yaml, or are they basically unused in analysis at present? I don't see any uses of them other than the code in postprocess.py that writes them.

I agree with John's names that specify TAI. I had previously hoped that we could just say that all MJDs are in TAI, but if the MPC is using TT then we really need to guard against mixing those up.