Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-7589

DateTime mishandles leap seconds

    Details

    • Sprint:
      Arch 2019-06-03, Arch 2019-06-10
    • Team:
      Architecture

      Description

      As Kian-Tat Lim discovered, daf::base::DateTime does not output the correct ISO string at a leap second: it does not print 60 in the seconds field. It likely also mishandles ISO input at the leap second.

      This may be difficult to fix and not worth the work. Another reasonable possibility is pick one standard uniform time system (TAI or TT) for its C++ time classes and stick to it, eliminating the need to deal with UTC and its complexities. If this is the chosen path it would help to decide soon as if nullifies DM-7587.

        Attachments

          Issue Links

            Activity

            Hide
            price Paul Price added a comment -

            Many observatories write UTC dates so we can't just dump support for that, and asteroid people really care about second-level precision so we need leap seconds.

            Surely these is a third-party library that handles times well?

            Show
            price Paul Price added a comment - Many observatories write UTC dates so we can't just dump support for that, and asteroid people really care about second-level precision so we need leap seconds. Surely these is a third-party library that handles times well?
            Hide
            rowen Russell Owen added a comment -

            I am not suggesting we drop support for UTC entirely, merely in our C++ DateTime class. We can use astropy.time for proper time support in Python, and I am doing so in DM-5503 for standardizing raw images in the camera mapper.

            Show
            rowen Russell Owen added a comment - I am not suggesting we drop support for UTC entirely, merely in our C++ DateTime class. We can use astropy.time for proper time support in Python, and I am doing so in DM-5503 for standardizing raw images in the camera mapper.
            Hide
            ktl Kian-Tat Lim added a comment -

            Finally figured out a way to fix this old ticket.

            Show
            ktl Kian-Tat Lim added a comment - Finally figured out a way to fix this old ticket.
            Hide
            rowen Russell Owen added a comment -

            I'm not sure what to do with this given RFC-503. But I looked at the code and found one possible bug (certainly very confusing code if it works correctly) and another suggestion. I appreciate the new unit test but am not sure it tests all the new code.

            Show
            rowen Russell Owen added a comment - I'm not sure what to do with this given RFC-503 . But I looked at the code and found one possible bug (certainly very confusing code if it works correctly) and another suggestion. I appreciate the new unit test but am not sure it tests all the new code.
            Hide
            ktl Kian-Tat Lim added a comment -

            It's simple; the implementation ticket for RFC-503 was never assigned to anyone, whereas I believe this old one was assigned to me. I agree that DM-15487 will be simpler to do, so I will kill this one.

            Show
            ktl Kian-Tat Lim added a comment - It's simple; the implementation ticket for RFC-503 was never assigned to anyone, whereas I believe this old one was assigned to me. I agree that DM-15487 will be simpler to do, so I will kill this one.

              People

              • Assignee:
                ktl Kian-Tat Lim
                Reporter:
                rowen Russell Owen
                Reviewers:
                Tim Jenness
                Watchers:
                John Parejko, Kian-Tat Lim, Paul Price, Russell Owen
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Summary Panel