[core] Handle leap second from chrono time types correctly #428
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
chrono 0.4.31 has stricter constraints in time constructor functions, so the cases where a leap second is not allowed are already covered here.
This in turn revealed that
dicom-core
is not accepting valid times with a leap second from chrono because they are represented differently: whereas our DICOM date time types represent leap seconds as having 60 seconds, like in the encoding of DICOM VRs DT and TM, chrono represents them instead as sub-second fractions larger than 1 second. This requires the seconds and microseconds from these types to be adapted to fit inDicomTime
andDicomDateTime
.Resolves the CI error detected in #427.
Summary
chrono
to^0.4.31
DicomTime::from_hms_micro
TryFrom
impls forDicomTime
andDicomDateTime
so that leap years in chrono types are correctly accounted for