Support -0000 as a valid UTC tz in rfc2822

This is a time that is commonly set in some environments, and RFC 5322
explicitly clarifies that we should treat -0000 as UTC[1][2] when interpretting
rfc2822.

Fixes #102

[1]: https://github.com/chronotope/chrono/issues/102#issuecomment-557846931
[2]: https://tools.ietf.org/html/rfc5322#section-3.3
This commit is contained in:
Brandon W Maister 2019-11-30 16:38:42 -05:00
parent 596aa19104
commit b553798f86
4 changed files with 8 additions and 9 deletions

View File

@ -10,6 +10,11 @@ Versions with only mechanical changes will be omitted from the following list.
## next ## next
### Improvements
* Support "negative UTC" in `parse_from_rfc2822` (@quodlibetor #368 reported in
#102)
### Internal improvements ### Internal improvements
* Use Criterion for benchmarks (@quodlibetor) * Use Criterion for benchmarks (@quodlibetor)

View File

@ -2051,6 +2051,8 @@ mod tests {
assert_eq!(DateTime::parse_from_rfc2822("Wed, 18 Feb 2015 23:16:09 +0000"), assert_eq!(DateTime::parse_from_rfc2822("Wed, 18 Feb 2015 23:16:09 +0000"),
Ok(FixedOffset::east(0).ymd(2015, 2, 18).and_hms(23, 16, 9))); Ok(FixedOffset::east(0).ymd(2015, 2, 18).and_hms(23, 16, 9)));
assert_eq!(DateTime::parse_from_rfc2822("Wed, 18 Feb 2015 23:16:09 -0000"),
Ok(FixedOffset::east(0).ymd(2015, 2, 18).and_hms(23, 16, 9)));
assert_eq!(DateTime::parse_from_rfc3339("2015-02-18T23:16:09Z"), assert_eq!(DateTime::parse_from_rfc3339("2015-02-18T23:16:09Z"),
Ok(FixedOffset::east(0).ymd(2015, 2, 18).and_hms(23, 16, 9))); Ok(FixedOffset::east(0).ymd(2015, 2, 18).and_hms(23, 16, 9)));
assert_eq!(DateTime::parse_from_rfc2822("Wed, 18 Feb 2015 23:59:60 +0500"), assert_eq!(DateTime::parse_from_rfc2822("Wed, 18 Feb 2015 23:59:60 +0500"),

View File

@ -73,10 +73,6 @@ fn parse_rfc2822<'a>(parsed: &mut Parsed, mut s: &'a str) -> ParseResult<(&'a st
// by adding 1900. note that four-or-more-digit years less than 1000 // by adding 1900. note that four-or-more-digit years less than 1000
// are *never* affected by this rule. // are *never* affected by this rule.
// //
// - zone of `-0000` and any unrecognized legacy time zones (including
// *every* one-letter military time zones) are considered "missing",
// in such that we don't actually know what time zone is being used.
//
// - mismatching day-of-week is always an error, which is consistent to // - mismatching day-of-week is always an error, which is consistent to
// Chrono's own rules. // Chrono's own rules.
// //

View File

@ -308,11 +308,7 @@ pub fn timezone_offset_2822(s: &str) -> ParseResult<(&str, Option<i32>)> {
} }
} else { } else {
let (s_, offset) = timezone_offset(s, |s| Ok(s))?; let (s_, offset) = timezone_offset(s, |s| Ok(s))?;
if offset == 0 && s.starts_with('-') { // -0000 is not same to +0000 Ok((s_, Some(offset)))
Ok((s_, None))
} else {
Ok((s_, Some(offset)))
}
} }
} }