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 (a pure finite number; inf/nan are rejected as non-finite) 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.

Within that order, the first byte selects which families can match at all. Every family gate is ^-anchored on either a digit or a letter, so a letter-leading input cannot match any of the numeric families and vice versa. Running them anyway costs roughly 5-10 ns each in regex startup even when the first byte rejects immediately, which is most of the cost of a non-date word — the dominant input in a qsv stats --infer-dates run over a text column.

rfc2822 stays in the digit branch as well as the letter branch: the day-of-week is optional in RFC 2822, so 02 Jun 2021 06:31:39 GMT parses and leads with a digit.