ninglinLiu opened a new issue, #7224:
URL: https://github.com/apache/datafusion-comet/issues/7224
### Describe the bug
The native `CAST(string AS TIMESTAMP)` returns NULL for a zone offset that
has a non-zero seconds part, and raises `CAST_INVALID_INPUT` under ANSI mode.
Spark accepts these offsets through `ZoneId.of` and returns a value.
The cause is that the native cast resolves offsets to an arrow `Tz`, which
has minute precision, so an offset such as `+08:00:30` cannot be represented.
This was already the behavior before #7215, which added the `+HH:MM:SS` form
for offsets whose seconds part is zero.
`CometCast` reports `String -> Timestamp` as `Compatible()`, and the
compatibility guide says Comet supports all formats Spark accepts, so this is a
gap in that claim.
### Steps to reproduce
```sql
SELECT cast('2020-01-01 12:34:56 +08:00:30' AS timestamp);
SELECT cast('2020-01-01 12:34:56 UTC+08:00:30' AS timestamp);
SELECT cast('2020-01-01 12:34:56 -01:30:15' AS timestamp);
```
Spark returns `2020-01-01 04:34:26` (session time zone UTC) for the first
query. Comet returns NULL, or raises `CAST_INVALID_INPUT` with
`spark.sql.ansi.enabled=true`.
### Expected behavior
Either the native cast handles second-precision offsets (for example by
applying the offset in seconds instead of building a `Tz`), or Comet falls back
to Spark for these inputs, and the compatibility guide documents the gap until
then.
### Additional context
Raised by @andygrove in the review of #7215.
This issue was written with AI assistance.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
