Struct Parse 

pub struct Parse<'z, Tz2> { /* private fields */ }

Parse struct has methods implemented parsers for accepted formats.

Implementations

impl<'z, Tz2> Parse<'z, Tz2>

where Tz2: TimeZone,

pub const fn new(tz: &'z Tz2, default_time: NaiveTime) -> Self

Create a new instance of Parse with a custom parsing timezone that handles the datetime string without time offset.

pub const fn prefer_dmy(&mut self, yes: bool) -> &Self

pub const fn new_with_preference( tz: &'z Tz2, default_time: NaiveTime, prefer_dmy: bool, ) -> Self

Create a new instance of Parse with a custom parsing timezone that handles the datetime string without time offset, and the date parsing preference.

pub fn parse(&self, input: &str) -> Result<DateTime<Utc>>

This method tries to parse the input datetime string with a list of accepted formats. See more examples from Parse, crate::parse() and crate::parse_with_timezone().

Order rationale: the regex-gated families are tried first because their is_match gate rejects non-matching inputs cheaply. The two parsers without a family regex gate — unix_timestamp (runs fast_float2) and rfc2822 (runs parse_from_rfc2822) — are tried last to avoid paying their cost on the common ISO/slash dates. Each still applies its own cheap byte pre-filter before the heavy parse (unix_timestamp checks the first byte against the leads fast_float2 accepts; rfc2822 requires a :).

This reorder is result-preserving:

• A fast_float2-parseable input (pure number, or inf/nan) matches no family gate (they all require /, an interior -, or a letters+space shape a bare number lacks), so it still reaches unix_timestamp.
• An rfc2822 input always carries a timezone, which makes the $-anchored month_dmy_* regexes fail; conversely month_dmy_* only succeeds without a timezone, which makes rfc2822 fail. The two are mutually exclusive, so deferring rfc2822 cannot change any result.