mjdnow() function produces incorrect UTC result (ignores leap seconds)

[genghisken]

This has always bugged me in Pan-STARRS and ATLAS, and now the issue has come up in LSST.

This topic was raised on the Community Forum. The midpointMjdTai value is in atomic time (TAI). This differs from UTC by (currently) 37 leap seconds. Which means we need to subtract 37 seconds from the mjdnow() result.

For historic observations (e.g. in ZTF) this is more complicated, since we have to check the year before doing the subtraction. But if ZTF derive MJD from UTC, then it's irrelevant.

See https://community.lsst.org/t/question-about-midpointmjdtai-to-utc-conversion-in-recent-rubin-alerts/11976

[genghisken]

Incidentally in ATLAS, the MJD is already in UTC. I suspect it's the same in Pan-STARRS.

[genghisken]

It is NOT the same in Pan-STARRS. Pan-STARRS also uses TAI.

[RoyWilliams]

One of my duties in LIGO was updating and implementing the leap-seconds to get accurate UTC conversion. LIGO uses GPS time, which is I think constant 19 seconds different from TAI, but neither GPS nor TAI have the leap-second disease that UTC has.

Given that Lasair is not interested in solar system, I suggest that we simply ignore the 34 second difference, as it makes no difference to a supernova. I suppose if we were very keen, we could change the name mjdnow() to mjdtainow().