Skip to content

GH-54643: [C++] Reject impossible dates and a zero day in the strptime timestamp parser - #54657

Draft
pearu wants to merge 1 commit into
apache:mainfrom
pearu:pearu/strptime-invalid-dates
Draft

pearu wants to merge 1 commit into
apache:mainfrom
pearu:pearu/strptime-invalid-dates

Conversation

@pearu

@pearu pearu commented Oct 19, 2026

Copy link
Copy Markdown
Contributor

Rationale for this change

strptime checks the day of month against 31 at most, and some implementations (macOS, the vendored musl used on Windows) accept day 00. The parser rolled an impossible date such as February 30 over into the next month, and took a zero day as the first of the month.

What changes are included in this PR?

The parser rejects the parsed date if it is not valid, as the ISO-8601 parser does. To tell a zero day from an omitted one, the day is initialized to the first before parsing, instead of being raised to the first afterwards. The two fixes are in one PR because the zero-day fix relies on the date check.

Are these changes tested?

Yes, in TimestampParser.StrptimeParser (impossible dates, a zero day, and February 29 of a leap year) and TimestampParser.StrptimeWithoutDay (a format without a day directive still gives the first of the month). The zero-day case only fails without the fix on platforms whose strptime accepts day 00.

Are there any user-facing changes?

Impossible dates and a zero day no longer parse with strptime formats.

AI usage disclosure

Developed with AI assistance (Claude Code): the fix, the tests and this description were AI-generated under my direction and reviewed line by line by me. I own and can debug these changes. No copyrighted material is included.

@github-actions github-actions Bot added the awaiting review Awaiting review label Oct 19, 2026
@github-actions

Copy link
Copy Markdown

Thanks for opening a pull request!

This pull request has been automatically closed because you currently have 4 open pull requests, which is more than the limit of 3.

Due to the increase in pull requests opened by AI bots, and in order to keep the review queue manageable, Apache Arrow limits contributors without repository access to at most 3 concurrently open pull requests. This helps make sure each pull request gets the attention it needs and that work in progress does not go stale.

Once one of your other open pull requests has been merged or closed, you are welcome to reopen this one.

See also:

@github-actions github-actions Bot closed this Oct 19, 2026
@github-actions

Copy link
Copy Markdown

⚠️ GitHub issue #54643 has been automatically assigned in GitHub to PR creator.

@pearu

pearu commented Oct 20, 2026

Copy link
Copy Markdown
Contributor Author

@kou, @ianmcook: #54656 has landed, so I tried to reopen this PR as the PR limit bot suggests, but GitHub refuses with "Could not open the pull request", presumably because the PR was closed by the bot rather than by me. Could one of you reopen it?

…trptime timestamp parser

strptime checks the day of month against 31 at most, and some
implementations (macOS, the vendored musl used on Windows) accept day 00.
The parser rolled impossible dates such as February 30 over into the next
month and took a zero day as the first of the month.

Initialize the day to the first before parsing, so that a format without a
day directive still gives the first of the month, and reject the result if
it is not a valid date, as the ISO-8601 parser does.

Drafted by Claude Code (an AI agent) and reviewed & approved by pearu.
@pearu
pearu force-pushed the pearu/strptime-invalid-dates branch from b46d111 to 7ac2429 Compare October 20, 2026 14:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants