pearu commented on PR #50146: URL: https://github.com/apache/arrow/pull/50146#issuecomment-6144888032
Following this review round I also probed the date/time parsing with other malformed inputs, to look for more of the same kind of issue. Rejected as expected, for date and time columns with ISO-8601 and/or strptime parsers: - out-of-range fields: month 13, February 30, `24:00:00`, `23:60:00`, `25:00:00`, `12:61:00`, day 32; - malformed fractions: `14:30:00.`, 10 digits, `14:30:00,5`, `14:30.5`, and fractions too fine for the time unit (`.5` → `time32[s]`, 4 digits → `time32[ms]`, 7 digits → `time64[us]`); - wrong separators (`2020-03-15X14:30:00`, double space, `2020/03/15`), signs and lengths (`+2020-03-15`, `20200-03-15`, `2020-3-5`), zone offsets with or without a fraction, partial strptime matches and trailing text. Two more issues turned up and are fixed in this push: impossible dates via strptime (1e9bf12849, mentioned in the leap-second thread), and a format with only `%p` producing midnight for time columns (folded into 20deafe068). Two behaviors are left as they are, since they come from strptime itself and also apply to timestamp columns on `main`: with glibc, `%p` affects only an hour parsed with `%I` (so `07 PM` with `%H %p` gives 07:00), and formats without a day or month directive default them (e.g. `%Y` gives January 1). -- 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]
