Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-219

Add support to daf::base::DateTime for TAI strings

    Details

    • Type: RFC
    • Status: Implemented
    • Resolution: Done
    • Component/s: DM
    • Labels:
      None

      Description

      The current lsst::daf::base::DateTime can only read and write ISO8601 strings as UTC. This means it cannot easily be used to read or write FITS header dates, which have the following requirements:

      • TAI dates are supported, by setting TIMESYS=TAI (very useful, since TAI is a uniform time system, so it makes a logical choice for recording dates)
      • FITS ISO8601 dates cannot contain a "Z" (or other time zone character)

      I propose the following modifications:

      • DateTime(std::string const& iso8601) gain a time system argument that defaults to UTC. This is necessary in order to easily and correctly read valid FITS dates, e.g. for massaging raw data into our format.
      • DateTime.toString() gains two arguments:
        • a time system argument that defaults to UTC. This allows us to easily write TAI dates to our FITS files, which is a clear win.
        • a flag that controls whether to output the "Z". This saves the trouble of stripping that character manually, increasing the chances that programmers will write correct FITS dates. However, we can live without it if necessary.

      If accepted, I would like to implement this as part of DM-5503. If rejected then I suggest the following:

      • Always write dates as MJD TAI and never as ISO8601. This has two minor concerns:
        • MJD potentially loses some digits
        • ISO dates have some human readability advantages (though MJD is also nice for other reasons, which is probably why both are often written)
      • Do not support reading raw dates whose dates are ISO8601 TAI. I do not know if this will be a problem for any cameras that we presently support; in many cases dates are written as both MJD and ISO8601, giving us an alternative for reading, and of course many cameras write UTC dates.

        Attachments

          Issue Links

            Activity

            Hide
            tjenness Tim Jenness added a comment -

            I believe Russell Owen did try to fix all the code he knew about. Optional code that doesn't run tests that trigger the problem are harder to deal with.

            Show
            tjenness Tim Jenness added a comment - I believe Russell Owen did try to fix all the code he knew about. Optional code that doesn't run tests that trigger the problem are harder to deal with.
            Hide
            rhl Robert Lupton added a comment - - edited

            I interpreted "if it does not impact too much code" as either a promise to fix all occurrences, or to RFC the change separately.

            The fact that this the broken code is (currently) optional tells us that the calibration products are falling through the cracks.

            Show
            rhl Robert Lupton added a comment - - edited I interpreted "if it does not impact too much code" as either a promise to fix all occurrences, or to RFC the change separately. The fact that this the broken code is (currently) optional tells us that the calibration products are falling through the cracks.
            Hide
            tjenness Tim Jenness added a comment -

            It was acknowledged that code would break. pipe_drivers is an optional dependency of lsst_distrib by the looks of it.

            Show
            tjenness Tim Jenness added a comment - It was acknowledged that code would break. pipe_drivers is an optional dependency of lsst_distrib by the looks of it.
            Hide
            rhl Robert Lupton added a comment -

            Making timescale a required argument broke code (pipe/drivers/constructCalibs.py in v12_1). I'm not sure that it should have been attached to this RFC at the last minute.

            Show
            rhl Robert Lupton added a comment - Making timescale a required argument broke code (pipe/drivers/constructCalibs.py in v12_1). I'm not sure that it should have been attached to this RFC at the last minute.
            Hide
            rowen Russell Owen added a comment -

            Adopted as per K-T's design.

            I will also look into making timescale a required argument; if it does not impact too much existing code then I will do that, to avoid confusion.

            Show
            rowen Russell Owen added a comment - Adopted as per K-T's design. I will also look into making timescale a required argument; if it does not impact too much existing code then I will do that, to avoid confusion.

              People

              • Assignee:
                rowen Russell Owen
                Reporter:
                rowen Russell Owen
                Watchers:
                John Parejko, Kian-Tat Lim, Pim Schellart [X] (Inactive), Robert Lupton, Russell Owen, Tim Jenness
              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Planned End:

                  Summary Panel