Skip to content

GH-54650: [C++][Python] Use timestamp_parsers as a fallback for CSV date columns - #54661

Closed
pearu wants to merge 4 commits into
apache:mainfrom
pearu:pearu/csv-date-timestamp-parsers
Closed

pearu wants to merge 4 commits into
apache:mainfrom
pearu:pearu/csv-date-timestamp-parsers

Conversation

@pearu

@pearu pearu commented Oct 19, 2026 •

Copy link
Copy Markdown
Contributor

Rationale for this change

CSV columns typed as date32 or date64 are parsed only from the ISO-8601 format, and ConvertOptions::timestamp_parsers applies only to timestamp columns, so other date formats need reading as a timestamp and a cast.

What changes are included in this PR?

  • Date columns try timestamp_parsers after the ISO-8601 parser fails, and floor the parsed timestamp to the day boundary, as a cast from timestamp to date does. Values outside the range of date32/date64 are rejected.
  • strptime parsers without a date directive are skipped, so that e.g. "%H:%M:%S" does not turn a time into 1900-01-01.
  • With the ISO-8601 parser in timestamp_parsers, fractional seconds are accepted and discarded.
  • Type inference of date columns is unchanged and uses ISO-8601 only, so a value with a time of day is not inferred as a date.

This PR is the date part of #50146. It builds on #54656, #54657 and #54659, whose fixes its tests cover for date columns, and those must land first.

Are these changes tested?

Yes, Date32Conversion.UserDefinedParsers and Date64Conversion.UserDefinedParsers in C++, and test_dates_with_timestamp_parsers in Python.

Are there any user-facing changes?

Yes, timestamp_parsers now also applies to date32/date64 columns given in column_types. This is documented in the C++ CSV docs and the ConvertOptions docstring.

AI usage disclosure

Developed with AI assistance (Claude Code): the implementation, tests, documentation 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.

pearu added 4 commits October 19, 2026 21:50
…ime on Windows

The vendored musl strptime, used on Windows, handles %a, %A, %b, %B, %h,
%c, %p, %r, %x and %X only when nl_langinfo() is available, which it is
not on Windows. Provide a C-locale replacement for the items used.
ARROW_TEST_FALLBACK_LANGINFO compiles the replacement on other platforms.

Drafted by Claude Code (an AI agent) and reviewed & approved by pearu.
…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.
…arser

strptime accepts a seconds value of 60 (glibc also 61), and the parser added
it to the time of day, wrapping it into the next minute. Arrow cannot
represent leap seconds, and the ISO-8601 parser rejects them, so reject them
here too. The check applies only when the time of day is used, so Gandiva's
to_date, which ignores the time, still accepts such values.

Drafted by Claude Code (an AI agent) and reviewed & approved by pearu.
… CSV date columns

Columns explicitly typed as date32 or date64 were parsed only from the
ISO-8601 format. Try ConvertOptions::timestamp_parsers after the ISO-8601
parser fails, and floor the parsed timestamp to the day boundary, as a cast
from timestamp to date does. Strptime parsers without a date directive are
skipped, so that a time is not accepted with a default date. Type inference
of date columns is not affected.

Drafted by Claude Code (an AI agent) and reviewed & approved by pearu.
@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 #54650 has been automatically assigned in GitHub to PR creator.

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.

1 participant