There has been no activity here, so I wonder if it's because the approach is unacceptable. I'm willing to make corrections - I'm aware that returning a DicomDate and a DicomTime element from within the DicomDateTime type may look a bit awkward, for one.

However, returning both at the same time encourages using both when both are required, which is probably most of the time, and that'd be race-free, so if parasiting DicomDateTime for that purpose is considered bad design, maybe it can be rewritten as just an isolated function instead of an associated one.

Removing that part and leaving only DicomDateTime::now_local() and DicomDateTime::now_utc() is also OK.

I do see issues with into_separate(), as it involves string manipulation of an ambiguous grammar. A DT VR can contain a range, when used inside a query object for a C-FIND identifier. Furthermore, the DT specification allows omitting all fields beyond any given one; for example "2000" is a valid DT value that omits all fields beyond the year. It can also contain a timezone offset, which can be negative; for example, "-2000" is a time zone offset that can be contained as part of a DT element. So, 1999-2000 could be either the date/time 1999 with time zone offset -2000, or the date/time range covering from the start of 1999 to the end of 2000. (Arguably, that's an invalid timezone offset, as the standard specifies that the range of the offset is from -1200 to +1400, but discerning that just adds to the overall difficulty.)

It's quite difficult to handle all special cases than can arise in such situations. I guess that such a function could return an error if the DT is not complete at least up to the hours, because if there's no hour at least, there would be no valid DicomTime object to return. It could also return an error if the date/time represents a range. It's not clear what it should do in presence of multiple values (VM > 1), but that case should probably be contemplated as well in a generic into_separate() function.

In short, a generic function that splits any DicomDateTime into a DicomDate and a DicomTime is much harder than just producing a single value from the current date and time.

One way it could be made to work with little effort, however, is to only accept exactly the format produced by DicomDateTime::now_local() or now_utc() and err on others. Still, parsing that for verification purposes in order to give an error if it's not the expected format, is a bit involved without using regular expressions.

Those are good concerns, but wouldn't the textual ambiguity be located at the parsing level? A DicomDateTime already contains a DicomDate and a DicomTime underneath, and these are binary encoded types with compliant invariants.
If anything, we may revisit the existing date-time parsers to mitigate some of the situations mentioned here. I honestly do not remember right now how date ranges are parsed, though I know there was some level of consideration for this use case.

It is true that the operation might not succeed or lose some information due to the inherent variable precision of DT, so we would need to adjust the return type accordingly: (DicomDate, Option<DicomTime>). Users of the method would also lose the time zone if they split it into two parts, but we can also add a method pub fn into_parts(self) -> (DicomDate, Option<DicomTime>, Option<FixedOffset>) to the bunch.

impl DicomDateTime {
    fn into_separated(self) -> (DicomDate, Option<DicomTime>) {
        (self.date, self.time)
    }
}

You're totally right, of course. I didn't look at the implementation of DicomDateTime at all, I just focused on what the prior PR author did. I wasn't aware that a DicomDateTime was actually a DicomDate + Option<DicomTime> + Option<FixedOffset>; I was under the impression that the value was stored as a string, but if it's already like that, there's no problem in doing what you suggest. I'll work on that, thanks for the feedback.

Edit: By the way, wouldn't into_parts() be enough? You can always do something like let (date, time, _) = DicomDateTime::now_local().into_parts() if you're not interested in the offset.

Edit: By the way, wouldn't into_parts() be enough? You can always do something like let (date, time, _) = DicomDateTime::now_local().into_parts() if you're not interested in the offset.

Well yes, that would be enough. I was mostly following up on the idea of having a function which returned a date and time, but into_parts seems to make more sense in the end, and does not exclude us from considering into_separated or into_date_and_time in the future if deemed reasonable (which we might never do 🤔).

So, the patch was actually pretty simple. My only concern is if the documentation for into_parts() is insufficient.