I'm going to push an end date for the UTC correction to u/rhl/DM-29187 (which means that the LATISS data headers are correct), but I'm not planning to take over this ticket.

Furthermore the RASTART test fails:

    def test_fix_header(self):

        from astro_metadata_translator import fix_header

        from astro_metadata_translator.tests import read_test_file

        # Test that header fix up is working

        # Not all headers are used in metadata translation

        test_data = (

            ("latiss-AT_O_20210212_000006.yaml",

             dict(RASTART=260.1785517385836)),

            ("latiss-AT_O_20210210_000011.yaml",

             dict(RASTART=355.41750341182313)),

        )

It appears to use test data taken on the day that this problem was fixed!

Oh, sorry. The how-to-repeat is

repo = "/lsstdata/offline/teststand/NCSA_auxTel/gen2repo"

butler = dafPersist.Butler(repo)

dataId = dict(dayObs="2021-03-11" , seqNum=4)

calexp = butler.get("raw", dataId)

print(exposure.getMetadata().get("RAEND"), butler.get("raw_md", dataId).get("RAEND"))

That RASTART_IS_BAD date is when the values were complete garbage and should not be used.

https://github.com/lsst/obs_lsst/blob/master/python/lsst/obs/lsst/translators/latiss.py#L63 defines the RASTART_IS_HOURS date at which that was fixed to be degrees. There is no date for fixing the 37s correction because no-one had reported it fixed (see the discussion in DM-28783)

Do I assume that after the 12th the RASTART/DECSTART are correct in the header and do not need any fixes?

I think for the double correction I'm going to have to finally bite the bullet and add a sentinel to the header indicating that it's been fixed. I've been wary of doing that because I didn't want to surprise people when something weird appears in their header. Maybe I should use something like HIERARCH ASTROMETADATA HEADER FIXED = TRUE.

To clarify the situation inherited from DM-28783:

• At 2021-02-11T1845Z the headers were decimal degrees but had a 37s error in RASTART.
• At 2021-02-12T0000Z the 37s was fixed.

So it was less than 6 hours of data where the 37s error was a real problem.

Furthermore, the RASTART test will fail because even as I was fixing the translator to deal with the problem of the time offset the problem had been fixed but I had not been informed. This means that the data I was looking at was already correct. The reason I thought it needed fixing was that this did make the number closer to the target RA (260.178 [fixed] vs 260.181 [demand] vs 260.024 [header]).

I took your fix and sorted out the test.

I'm going to do the double fixup fix in a different ticket because that can be done entirely inside astro_metadata_translator.

Looks fine