pub enum SacOrGreg {
Gregorian(GregorianDate),
Sac13(Date),
}Expand description
EitherDate is either a GregorianDate or SAC13 Date.
Variants§
Gregorian(GregorianDate)
Variant wrapping a GregorianDate.
Sac13(Date)
Variant wrapping a SAC13 Date.
Implementations§
Source§impl SacOrGreg
impl SacOrGreg
Sourcepub fn greg(&self) -> Option<GregorianDate>
pub fn greg(&self) -> Option<GregorianDate>
If the inner variant is SacOrGreg::Gregorian it returns that, otherwise None.
Sourcepub fn sac13(&self) -> Option<Date>
pub fn sac13(&self) -> Option<Date>
If the inner variant is SacOrGreg::Sac13 it returns that, otherwise None.
Sourcepub fn parse_str(input: &str) -> Option<ParsedSacOrGreg>
pub fn parse_str(input: &str) -> Option<ParsedSacOrGreg>
Parses various SAC13 and Gregorian Calendar formats.
§Example
use sac13::prelude::*;
let parsed = SacOrGreg::parse_str("2009-07-03").unwrap();§Supported Formats
§Nomenclature
┌── leading whitespace
│
│ Separators trailing whitespace
┌──┴─┐ ┌┤ │ ┌───┴───┐
" 23, 12 -2007 "
└┤ └┤ └─┬─┘
Components§Exactly three numeric components
This function only allows dates that are represented by three numeric components, including SAC13 years with millenium indicator (technically it’s a base-26 digit). In fact SAC13 years must be written with a millenium indicator because that is used to disambiguate between SAC13 and Gregorian Calendar dates. Components must not have thousands separators (or similar group separators).
Textual representations/components like Gregorian weekdays or full month names are not supported!
§Year first or last
The year component has to either be the first, or the third (and last) component. It must not be the second (middle) component. The allowed component orders are defined in the ComponentOrder enum.
If it’s a SAC13 date the year must always be exactly four digits long A000 - Z999.
For Gregorian Dates if any component is negative or zero, it is automatically assumed to be the year component.
Positive years must be at least three digits long so the component is clearly distinct from
the month and day component. If the year is positive but less than 100 it must be written with leading zeros.
Even though the actual supported formats allow for three digit Gregorian Calendar years, or even one digit if the year is negative, the best practice is to pad years to at least four digits.
The position of the year component implicitly defines the order of month and day, because all components are either in acending or decending order. There is one special case though: If it’s Gregorian Calendar date and the separators between all components are slashes, we assume the components to be a US formatted date with the order M/D/Y
§Separators
All ASCII characters that are not letters or digits, are allowed as separators;
they are one or more (at most six) characters long and can be pretty arbitrary.
Again, even though you can use almost anything as separators doesn’t mean you should.
You should especially avoid multi-character separators that end with dashes,
because they will be interpreted as a negative sign for the next component.
YYYY-MM-DD and YYYY - MM - DD are, of course, fine but using - as a separator,
like in YYYY -MM -DD, will (obvously?) lead to said problem,
because it will be interpreted as three components separated by spaces, with at least two
of them being negative. Note that + is never interpreted as a sign.
So, something like DD.- +MM+$%&/\YYYY can be parsed, but please don’t do that!
§ASCII only
The entire input must be valid ASCII. If you have some weird format, for example with emdash separators, you must replace them, for example with regular hyphens, before parsing.
§Whitespace
Only spaces (0x20) are considered “whitespace” by this method. Leading and trailing whitespace are always trimmed, no matter how long. Whitespace in separators are considered part of the separator and recorded as is in the DateComponentSeparator.