UTC vs. MJD timestamps in survey output about desisurvey

[dkirkby]

I have no allegiance to MJD but let's not change anything in the next few weeks or adopt a standard that cannot be unambiguously represented with a float.

[dkirkby]

The scheduler and ETC only care about relative time, so the introduction of a UTC leap second during a night should have no impact.

The pre-tabulated ephemerides assume no new leap seconds during the survey, but are only used for forecasts which do not care about an extra second. I suggest that we recompute the ephemerides file during the first full moon after a leap second is introduced, to minimize confusion.

I propose to continue using MJD internally in desisurvey since this can be unambiguously converted to a UTC timestamp (using astropy.time), when needed, for external use.

[schlafly]

Given the lack of activitity in the past three years and the fact that things have largely been baked in by survey start, I'm closing this; we don't want to change formats now.