tustvold commented on issue #3969: URL: https://github.com/apache/arrow-rs/issues/3969#issuecomment-1487143900
> It may be that we simply choose not to fix this regression as the previous implementation was working "by accident" Indeed, chrono's implementation of strptime is incredibly permissive, to the point where some of the undocumented behaviour is actually considered a bug - https://github.com/chronotope/chrono/issues/332. In particular [the docs](https://docs.rs/chrono/0.4.24/chrono/format/strftime/index.html) state that `%m` and similar expect 0 padded inputs, however, the implementation is more permissive. We strive to support RFC3339 and reasonable variants thereupon, we therefore added additional cases based on chrono's strptime to supplement chrono's very rigid RFC3339 support, which in turn led to chrono's permissive strptime implementation leaking through arrow's parsing abstraction. Given RFC3339 requires that days and months should be [two digits](https://www.rfc-editor.org/rfc/rfc3339#page-8) and years must be [4 digits](https://www.rfc-editor.org/rfc/rfc3339#page-4), and we have never claimed support for such timestamps, I do not personally consider this a regression and do not plan to change it. That being said if someone wants to contribute additional functionality for this and is able to do so in a way that doesn't regress parsing performance, I would be fine with it. The major motivation for not supporting it, is that knowing ahead of time the character layout is what allows the parser to be more efficient than otherwise. -- 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]
