Skip to content

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

Merged
kou merged 2 commits into
apache:mainfrom
pearu:pearu/strptime-invalid-dates
Oct 21, 2026
Merged

kou merged 2 commits 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, and the vendored musl also month 00. The parser rolled an impossible date such as February 30 over into the next month, took a zero day as the first of the month, and a zero month as December of the previous year.

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. The vendored musl strptime also gets back the unsigned range check that upstream musl has, so it rejects day and month 00 itself.

Are these changes tested?

Yes, in TimestampParser.StrptimeParser (impossible dates, a zero day, a zero month, 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 and zero month cases only fail without the fix on platforms whose strptime accepts them.

Are there any user-facing changes?

Impossible dates, a zero day and a zero month 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
@pearu
pearu marked this pull request as ready for review October 20, 2026 15:05

@kou kou left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

"2/29/2001 12:34:56",
// A zero day is rejected rather than
// taken as the first of the month
"2/00/2000 12:34:56"};

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you also add a zero month case?

BTW, could you also apply this change?

diff --git a/cpp/src/arrow/vendored/musl/strptime.c b/cpp/src/arrow/vendored/musl/strptime.c
index eb325108b8..13c0f3172d 100644
--- a/cpp/src/arrow/vendored/musl/strptime.c
+++ b/cpp/src/arrow/vendored/musl/strptime.c
@@ -212,7 +212,7 @@ char *strptime(const char *__restrict s, const char *__restrict f, struct tm *__
 			*dest = 0;
 			for (i=1; i<=min+range && isdigit(*s); i*=10)
 				*dest = *dest * 10 + *s++ - '0';
-			if (*dest - min >= range) return 0;
+			if ((unsigned)(*dest - min) >= (unsigned)range) return 0;
 			*dest -= adj;
 			switch((char *)dest - (char *)tm) {
 			case offsetof(struct tm, tm_yday):

The upstream has (unsigned)range here: https://git.musl-libc.org/cgit/musl/plain/src/time/strptime.c

Our vendored version doesn't have it. It may have been removed to avoid a -Wsign-compare warning. So I also cast *dest - min to unsigned to avoid the warning.

The change in this PR fixes the problem caused by this difference. So this change isn't strictly needed. But I want to keep our vendored version as close to the upstream as possible.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added 0/15/2000 12:34:56: with the vendored strptime on main it became 1999-12-15. Also applied your change; with it the vendored strptime rejects day and month 00 itself, as glibc does.

@github-actions github-actions Bot added awaiting merge Awaiting merge and removed awaiting review Awaiting review labels Oct 21, 2026
Drafted by Claude Code (an AI agent) and reviewed & approved by pearu.
@kou
kou merged commit 6e4fa50 into apache:main Oct 21, 2026
61 of 63 checks passed
@kou kou removed the awaiting merge Awaiting merge label Oct 21, 2026
@kou

kou commented Oct 21, 2026

Copy link
Copy Markdown
Member

Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants