Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

arrow-cast: Date32, Timestamp and Time64 parsers reject surrounding whitespace that numeric parsers accept

Closed Beginner friendly
  • Is something wrong?
#11,225 2 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
data

Research direction

Start in arrow-cast at Date32Type::parse and locate the corresponding Timestamp and Time64 parsers. Compare the parser changes from #10374 and #10396, then verify the reproduction for padded and already-trimmed values; done means surrounding ASCII whitespace is accepted for all three temporal types without regressing unpadded inputs.

Written by the indexing model from the issue text.

Description

Describe the bug

Since #10374 and #10396, the integer and float parsers in arrow-cast accept leading and trailing whitespace, but the Date32, Timestamp and Time64 parsers still reject it. With the default CastOptions (safe: true) a padded date or time does not error, it quietly becomes NULL.

To Reproduce

Casting StringArray::from(vec![padded, padded.trim()]) with arrow-cast 60.0.0:

Int32        " 12 "                    padded null=false  | safe=false: ok
Float64      " 1.5 "                   padded null=false  | safe=false: ok
Date32       " 2024-01-05 "            padded null=true   | safe=false: Cast error: Cannot cast string ' 2024-01-05 ' to value of Date32 type
Timestamp    " 2024-01-05T10:00:00 "   padded null=true   | safe=false: Parser error: Error parsing timestamp from ' 2024-01-05T10:00:00 ': error parsing date
Time64(µs)   " 10:00:00 "              padded null=true   | safe=false: Cast error: Cannot cast string ' 10:00:00 ' to value of Time64(µs) type

The trimmed value parses in every case. Date32Type::parse still goes straight to parse_date_to_days on main.

Seen through DataFusion main: SELECT CAST(' 12 ' AS INT) returns 12, while SELECT CAST(' 2024-01-05 ' AS DATE) fails with Failed to cast field 'lit' from Utf8 to Date32. PostgreSQL accepts both.

Expected behavior

The temporal parsers treat surrounding ASCII whitespace the same way the numeric ones now do.

Additional context

I'd be happy to send a PR. The shape would follow #10374 and #10396: try the input as-is first and trim only when that fails, so values without padding take no extra cost.

Found with Claude Code (Claude Opus 5.5), comparing DataFusion against PostgreSQL 17. The reproduction above was run here.

Dominant language
Rust
Stars
3.6k
Forks
1.4k
Avg merge
3d 46m
Merged PRs (30d)
238

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/arrow-rs

All issues in apache/arrow-rs

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.