Revamp DICOM datetime

[jmlaka]

Please see this DicomDateTime rewrite that now can handle time zone aware and naive values.
External FixedOffset values no longer required.
some methods deprecated
some methods documented to be not optimal use of API
Breaking changes
This should fix #452

Thank you !

[jmlaka]

Hello, @Enet4. Please check out this pull request.

My initial questions:
Maybe the [PreciseDateTimeResult] struct name is too long ?

The core crate now requires the "clock" feature for chrono library, I don't know if this is acceptable.
It's needed for the default handling of an ambiguous DT range, where one time zone is parsed and the second one is missing.

Also, for different parsing behavior of this situation a PrimitiveValue:to_datetime_range_custom<T> was added. I'm not sure if you are ok with such addition.

I'm not sure if I deprecated some methods correctly ...

Thanks

[Enet4]

Thank you very much for working on this, @jmlaka. I haven't had much time to review things properly, but it would be nice to bring a new version of DICOM-rs the next few months, so I'm aiming for that.

Maybe the [PreciseDateTimeResult] struct name is too long ?

It should be OK. The only alternative I can think of is PreciseDtResult, but that would reduce the size of the most important part of the type in the name.

The core crate now requires the "clock" feature for chrono library, I don't know if this is acceptable.It's needed for the default handling of an ambiguous DT range, where one time zone is parsed and the second one is missing.

Interesting, I did not recall that we were excluding some of the default features. As long as it still builds against major platforms and wasm32, it should be fine. If not, we could try some feature gating.

Also, for different parsing behavior of this situation a PrimitiveValue:to_datetime_range_custom was added. I'm not sure if you are ok with such addition.

At first glance the name to_datetime_range_custom is not very clear about what custom entails, but considering that it's a custom interpretation (or disambiguation) of the range, I don't see a better name for it. I will strive for a more thorough review on this part next week or so.

I'm not sure if I deprecated some methods correctly

I left a note on that in the inline comments.

[jmlaka]

I fixed the problems you mentioned.
The DicomDateTime had methods, which, on second thought, were superfluous.

[Enet4]

Things look pretty good! I just have a few more changes to suggest, and then we can merge.

[Enet4]

I hope you don't mind, I added in a few more changes before merging. Here is the summary:

• Adjusted the documentation around parse_datetime_partial, parse_datetime, PreciseDateTime, and the ambiguous DT parsers.
• Readjusted the methods in PreciseDateTime to better reflect its nature as a sum type of chrono date-time values.
• Made a custom PartialOrd implementation for PreciseDateTime because the derived one would be misleading. Because of how PartialOrd is derived, it could occur 2024-03-01 00:00:00 +00 being larger than 2024-03-01 23:59:59, much to the surprise of its users, just because it had a time zone specified.
• Moved PreciseDateTime to live alongside the other DICOM date/time types.
• Added impl FromStr for DicomDateTime.

With this, I think we are ready to move forward. :)

[jmlaka]

Thank you very much for your added insight.
Happy to help.

[Enet4]

Thank you once again. 👍 We're bringing this in.