pub trait AmbiguousDtRangeParser {
// Required methods
fn parse_with_ambiguous_start(
ambiguous_start: NaiveDateTime,
end: DateTime<FixedOffset>,
) -> Result<DateTimeRange, Error>;
fn parse_with_ambiguous_end(
start: DateTime<FixedOffset>,
ambiguous_end: NaiveDateTime,
) -> Result<DateTimeRange, Error>;
}
Expand description
The DICOM standard allows for parsing a date-time range
in which one DT value provides time-zone information
but the other one does not.
An example of this is the value 19750101-19800101+0200
.
In such cases, the missing time-zone can be interpreted as the local time-zone the time-zone provided by the upper bound, or something else altogether.
This trait is implemented by parsers handling the aforementioned situation. For concrete implementations, see:
ToLocalTimeZone
(the default implementation)ToKnownTimeZone
FailOnAmbiguousRange
IgnoreTimeZone
Required Methods§
Sourcefn parse_with_ambiguous_start(
ambiguous_start: NaiveDateTime,
end: DateTime<FixedOffset>,
) -> Result<DateTimeRange, Error>
fn parse_with_ambiguous_start( ambiguous_start: NaiveDateTime, end: DateTime<FixedOffset>, ) -> Result<DateTimeRange, Error>
Retrieve a DateTimeRange if the lower range bound is missing a time-zone
Sourcefn parse_with_ambiguous_end(
start: DateTime<FixedOffset>,
ambiguous_end: NaiveDateTime,
) -> Result<DateTimeRange, Error>
fn parse_with_ambiguous_end( start: DateTime<FixedOffset>, ambiguous_end: NaiveDateTime, ) -> Result<DateTimeRange, Error>
Retrieve a DateTimeRange if the upper range bound is missing a time-zone
Dyn Compatibility§
This trait is not dyn compatible.
In older versions of Rust, dyn compatibility was called "object safety", so this trait is not object safe.