time: parse_http_header_string#26636
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5b96e76620
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if r := parse_format(f, 'DD MMM YYYY HH:mm:ss') { | ||
| return r | ||
| } | ||
| if r := parse_format(f, 'DD MMM YY HH:mm:ss') { |
There was a problem hiding this comment.
The RFC850 branch currently parses DD MMM YY HH:mm:ss directly, which maps YY into the current century, so inputs like Sunday, 06-Nov-94 08:49:37 GMT resolve to 2094 when run today instead of 1994. That breaks legacy HTTP-date parsing and can produce incorrect expiration/cache times for any obsolete RFC850 header with a year suffix greater than the current year suffix.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
@Bruno-Vdr can you take care of this change? Shouldn't take more than checking year > current year, add century - 1, else add century.
There was a problem hiding this comment.
I will do it soon.
There was a problem hiding this comment.
I need help here:
Tuesday, 06-Nov-94 11:07:09 GMT should map to 1994 (because otherwise it points to future date).
Friday, 06-Nov-20 08:49:37 GMT should map on 2020 instead of 1920 because at this time http header weren’t widely used ? If this last statement is true, I don't need to add a century, because it already maps to this century. Am I Right ?
There was a problem hiding this comment.
94 > 26, so should map to 1994. 20 <= 26, so should map to 2020. If a 4-digit year is given, it should be used as-is.
As long as the automatic handling treats <= current year as being in current century, you are correct that you don't need to add the century... through when you parse it, it would be more consistent to add it anyway.
…red to be from the previous century.
…red to be from the previous century.
* Implemented rfc2616 parse_http_header_string. * Corrected typos. * Update vlib/time/parse_test.v * Fixed YY date issue. If parsed year exceed current year, it's considered to be from the previous century. --------- Co-authored-by: Swastik Baranwal <swstkbaranwal@gmail.com>
4 participants
An attempt to implement #26166 feature.