...and because parse_header() is too lenient, gix::date::parse() is also too lenient.
#[test]
fn parse_header_is_too_lenient() {
let now = SystemTime::now();
for not_a_header_str in ["2005-04-07T22:13:09", "2005-04-07 22:13:09"] {
assert_eq!(
gix_date::parse_header(not_a_header_str),
Some(Time {
seconds: 2005,
offset: 0
})
);
assert_eq!(
gix_date::parse(not_a_header_str, Some(now)).unwrap(),
Time {
seconds: 2005,
offset: 0
}
);
}
} Expected behavior 🤔
#[test]
fn parse_header_is_too_lenient() {
let now = SystemTime::now();
for not_a_header_str in ["2005-04-07T22:13:09", "2005-04-07 22:13:09"] {
assert!(gix_date::parse_header(not_a_header_str).is_none());
assert!(gix_date::parse(not_a_header_str, Some(now)).is_err());
}
}
These come into play in StGit in the context of parsing command line arguments that set/modify either the author or commit date. We try to accommodate these iso8601-like strings that are missing the timezone specifier with the policy that if the timezone specifier is missing, we assume the user meant the local timezone.
Updating gix-date from 0.9.4 to 0.10.3 triggers a regression in this StGit code:
To work around this in StGit, I'd have to bypass using gix::date::parse() and instead write my own similar version with the stricter semantics I'm indicating in this issue. Would be nice to be able to get this behavior from gix.
I also note this comment from gix_date::parse() that seems to indicate that this problem may be on your radar somewhere (@Byron).
As always, thank you for your tremendous effort on gitoxide!
Git behaviorNo response
Steps to reproduce 🕹No response
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4