Repository navigation
datetime: strict RFC 5322 parsing with a failure signal - #2
Merged
Merged
Conversation
The parser matched zone names by their first one or two letters, so IST came out as military zone I (-0900) and CEST as CDT. RFC 5322 section 4.3 says both military zones and unrecognized names are to mean -0000.
The parser always claimed to have consumed the whole input, and its recovery for ill-formed dates produces plausible but wrong values, so a caller could not tell a date from garbage. Try the RFC 5322 grammar first. Only if that fails, fall back to the old heuristics and leave newPosition at the start.
"Thu Nov 18 12:11:16 2004" has the year after the time, which was ignored and replaced by the current year. Make it work.
The broken-down UTC time was labeled with the given zone instead of being converted to it, yielding a different instant.
jengelh
force-pushed
the
datetime-strict
branch
2 times, most recently
from
September 30, 2026 14:39
418166a to
e23c3e5
Compare
The heuristic parser accumulated day, time, year and zone digits without bound. Limit them like the strict path does.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
datetime::parse() had no way to report malformed input, and its recovery heuristics yield plausible but wrong values (current year for asctime dates, "May" eaten as weekday, IST read as military zone I). Consumers such as gromox had to second-guess the result.
strict RFC 5322 path (incl. obsolete syntax and comments); newPosition stays at the start position when the input is not well-formed, the old heuristics still fill the fields
zone names per RFC 5322 section 4.3
asctime year taken from the input
datetime(time_t, zone) converts to the zone
new datetimeUtils::toTimeT
no signed overflow on long digit runs in the heuristic parser