Issues with too early dates? about dicom-rs

[drewhk]

I am happy to take a look! It might help deepen my DICOM studies :D I am happy to have your guidance here!

[Enet4]

Thank you for reporting! This issue might be isolated enough to reproduce with a fine-grained test. I would be interested in knowing if there are any other attributes which could have triggered the error. Is there anything with the DT value representation? The DateTimeZone error value is currently documented as an "Invalid or ambiguous combination of date with time", which suggests that a date-time is involved.

[Enet4]

Just a heads up, the tests show that those attributes are decoded just fine. This is very likely an issue with decoding a particular date-time in that data set. Whenever you have the time to provide the DT values which may trigger the error, I'd very much appreciate it.

[drewhk]

Yes, it turns out there is a seemingly malformed field:

(0010,0030) DA [1902]                                   #   4, 1 PatientBirthDate

I am new to dicom, but this looks like wrong to me. Nevertheless this is the data I have...

[Enet4]

Indeed, this is yet another pseudo-DICOM value. While the standard mandates the presence of all 3 date components (YYYYMMDD), a significant number of systems out there have the habit of producing dates in non-conforming formats.

With that said, the current behavior of the parser is to decode DICOM values inline as they are found in the data set, and I wish to move away from this behavior in the future (see #12). Still, the custom date decoding routine could be made more flexible by allowing the month and day to default to 1.
If you would like to give a shot at making this change with my guidance, please let me know. Otherwise, I can look into it eventually.

[Enet4]

I am glad! The date and time decoding functions are in the encoding crate, in this file. I would recommend taking a test-driven approach:

1. Head down to the tests module and include the date value to be tested ("1902") in the appropriate test function. The test should then fail on cargo t, given the circumstances.
2. Fix the function until the test passes.

I suspect that the custom date parser was already prepared for shorter values, but it was probably left untested and buggy.

[drewhk]

Aaah, you did it before I finally managed to get spare some time to fix it... Thank you very much!