Thank you for the initiative! In the meantime I have already merged #665, but this can make a great addition to the 0.9 milestone!

I am not sure if Option<&u32> is the right choice as return type, or if i should create a new error variant if a mismatch between frac and frac_precision occurs.

An enum might be better, as it forcefully narrows down the precision depth to valid cases (10th of a second, 100th of a second, millisecond, ...). But this can stay an implementation detail as long as the API is expressive and flexible enough. Right now there are a few cases where it's still hard to retrieve the fraction of a second, and relaxing it to enable fetching this fraction regardless of precision may be a good step towards that.

Moreover, any method in this module returning Option<&u32> should return Option<u32> instead. In this case there is no added value to returning the reference to the value in the DicomTime, and Option<u32> is more compact and nicer to work with.

I took the liberty of reworking this pull request so that hopefully it will be easier to work with fractions of a second.

• I have decided to remove the fraction method entirely due to its ambiguity and difficulty of use. The former implementation (pre-PR) was particularly tricky to use because it required the fraction to be precise to the microsecond, which some devices do not even produce. And the implementation originally suggested in this PR would also require the user to consult the precision for it to be useful.
• So instead, we now have fraction_ms and fraction_micro, which always return at the requested precision, and only return None when the time does not specify any fraction of a second.
• I also added a few extra methods and trait implementations which make complete sense but were missing for some reason: FromStr for DicomDate and DicomTime.
• Remove also functions which were deprecated in version 0.7

Should be good now! Feel free to let me know if you encounter other quirks in this API.