pearu opened a new pull request, #54658: URL: https://github.com/apache/arrow/pull/54658
### Rationale for this change The parser computed the year as `tm_year + 1900`, which can overflow `int` (e.g. with `%s`), and passed it to `date::year`, which holds 16 bits, so a year out of range gave a wrong timestamp. ### What changes are included in this PR? The year is computed in 64 bits and rejected if `date::year` cannot hold it. ### Are these changes tested? Yes, `TimestampParser.StrptimeYearOutOfRange` covers a year that wraps around and one where `tm_year + 1900` overflows `int`. It needs `%s` and is skipped where `strptime` does not parse `%s` into 64 bits (e.g. on Windows). ### Are there any user-facing changes? Values whose year does not fit in 16 bits no longer parse with `strptime` formats. ### AI usage disclosure Developed with AI assistance (Claude Code): the fix, the test 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 Issue: #54646 -- 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]
