alamb commented on issue #8336: URL: https://github.com/apache/arrow-datafusion/issues/8336#issuecomment-1830063184
Another option is "do nothing" You can get the expected answer by using `to_timestamp_seconds`: ``` ❯ select to_timestamp_seconds(-62125747200); +-------------------------------------------+ | to_timestamp_seconds(Int64(-62125747200)) | +-------------------------------------------+ | 0001-04-25T00:00:00 | +-------------------------------------------+ 1 row in set. Query took 0.001 seconds. ``` I think the core issue is that the SQL type `TIMESTAMP` mapping (as documented in https://arrow.apache.org/datafusion/user-guide/sql/data_types.html#date-time-types) is: | SQL Type | Arrow Type | |--------|--------| | `TIMESTAMP` | `Timestamp(Nanosecond, None)` | There is no type in Arrow that can represent nanosecond precision over the same range of values as a i64 second timestamp. So if we switched to something like | SQL Type | Arrow Type | |--------|--------| | `TIMESTAMP` | `Timestamp(Second, None)` | That would result in lower precision timestamps (can't represent nanosecond precision) So basically I suggest we do nothing about this particular issue -- there is a workaround and I think it is a fairly uncommon corner case -- 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]
