[
https://issues.apache.org/jira/browse/SPARK-59860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SPARK-59860:
-----------------------------------
Labels: pull-request-available (was: )
> Fail on overflow in from_unixtime instead of wrapping around
> ------------------------------------------------------------
>
> Key: SPARK-59860
> URL: https://issues.apache.org/jira/browse/SPARK-59860
> Project: Spark
> Issue Type: Bug
> Components: SQL
> Affects Versions: 5.0.0
> Reporter: sepuri sai krishna
> Priority: Major
> Labels: pull-request-available
>
> {{from_unixtime}} converts seconds to microseconds with a plain {{Long}}
> multiplication, so for inputs beyond about 9.2 * 10^12 seconds the result
> silently wraps around and it returns a wrong timestamp string instead of
> failing. This happens with ANSI mode on and off, and in both codegen and
> interpreted mode:
> {code:sql}
> SET spark.sql.session.timeZone=UTC;
> SELECT from_unixtime(9223372036854); -- +294247-01-10 04:00:54
> (largest value that fits, correct)
> SELECT from_unixtime(9223372036855); -- -290308-12-21 19:59:05
> SELECT from_unixtime(9223372036854775807); -- 1969-12-31 23:59:59
> {code}
> One second past the largest value that fits jumps back by about 584,000
> years, and the maximum long value comes out as a plausible looking 1969
> timestamp.
> {{timestamp_seconds}} performs the same conversion and fails with
> {{DATETIME_OVERFLOW}} on these inputs, with ANSI mode on and off:
> {code:sql}
> SELECT timestamp_seconds(9223372036855);
> -- [DATETIME_OVERFLOW] Datetime operation overflow: create a TIMESTAMP from
> 9223372036855L seconds since the epoch.
> {code}
> {{from_unixtime}} should fail with the same error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
