amitvijapur opened a new pull request, #11179:
URL: https://github.com/apache/arrow-rs/pull/11179
# Which issue does this PR close?
Closes #8219.
# Rationale for this change
`string_to_datetime` documents RFC 3339 / ISO 8601 support, but
`TimestampParser::time` only accepts `HH:MM:SS` and `HHMMSS`, so an ISO 8601
time without seconds such as `2025-08-14T00:00Z` fails with `error parsing
time`. @alamb agreed on the issue that this form should parse, provided
performance is not hurt; the new arm sits after the existing `HH:MM:SS` and
`HHMMSS` arms, so those forms match before its guard runs. @klion26 offered to
fix it on 2025-09-08 and no PR followed in the year since, so I picked it up.
# What changes are included in this PR?
One more arm in `TimestampParser::time` accepts `HH:MM` when byte 16 is
neither a digit nor `:` nor `.`, so `HH:MM:SS`, `HH:MM:` and `HH:MM.f` keep
their current handling and errors. Seconds and nanoseconds are zero and the
timezone suffix is parsed as before. The doc list of accepted inputs gains the
new form.
One consequence: `Date32Type::parse("2020-09-08 01:02")` now succeeds, since
the string is a valid timestamp. The `parse_date32` test moves that input from
the error cases to the parsed ones.
# Are these changes tested?
`string_to_timestamp_without_seconds` checks four inputs (with `Z`, no
suffix, `+05:30`, and a lowercase `t` with `-08:00`) against their `:00` forms.
`string_to_timestamp_invalid` gains `09:2Z`, `09:26:Z`, `09:26.5Z` and
`09:61Z`, all still `error parsing time`. `cargo test -p arrow-cast` passes.
# Are there any user-facing changes?
Timestamps whose time has no seconds now parse in `string_to_datetime`, and
through it in the string to timestamp and date casts.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
