Skip to content

[SPARK-52848][SQL] Avoid cast to Double in casting TIME/TIMESTAMP to DECIMAL #51539

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
+15 −19
Open

[SPARK-52848][SQL] Avoid cast to Double in casting TIME/TIMESTAMP to DECIMAL #51539

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6ee0c78
Regen golden files
MaxGekk Jul 17, 2025
57aa895
Add comments
MaxGekk Jul 17, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 11 additions & 15 deletions sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/Cast.scala
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -727,9 +727,6 @@ case class Cast(
private[this] def timestampToDouble(ts: Long): Double = {
ts / MICROS_PER_SECOND.toDouble
}
private[this] def timeToDouble(timeNanos: Long): Double = {
timeNanos / NANOS_PER_SECOND.toDouble
}
private[this] def timeToLong(timeNanos: Long): Long = {
Math.floorDiv(timeNanos, NANOS_PER_SECOND)
}
Expand Down Expand Up @@ -1043,11 +1040,15 @@ case class Cast(
b => toPrecision(if (b) Decimal.ONE else Decimal.ZERO, target, getContextOrNull()))
case DateType =>
buildCast[Int](_, d => null) // date can't cast to decimal in Hive
case TimestampType =>
// Note that we lose precision here.
buildCast[Long](_, t => changePrecision(Decimal(timestampToDouble(t)), target))
case _: TimeType =>
buildCast[Long](_, t => changePrecision(Decimal(timeToDouble(t)), target))
case TimestampType => buildCast[Long](_, t => changePrecision(
// 19 digits is enough to represent any TIMESTAMP value in Long.
// 6 digits of scale is for microseconds precision of TIMESTAMP values.
Decimal.apply(t, 19, 6), target))
case _: TimeType => buildCast[Long](_, t => changePrecision(
// 14 digits is enough to cover the full range of TIME value [0, 24:00) which is
// [0, 24 * 60 * 60 * 1000 * 1000 * 1000) = [0, 86400000000000).
// 9 digits of scale is for nanoseconds precision of TIME values.
Decimal.apply(t, precision = 14, scale = 9), target))
Comment on lines +1043 to +1051
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we really sure that we always want to use fixed precision and scale here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have to use fixed scale at lest to get correct decimal. And precision should guarantee that we cover full input range.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that part is alright. However, as a consequence of this, we also get fixed precision/scale in error messages (e.g. #51539 (comment)). Let's continue the discussion over there.

case dt: DecimalType =>
b => toPrecision(b.asInstanceOf[Decimal], target, getContextOrNull())
case t: IntegralType =>
Expand Down Expand Up @@ -1506,18 +1507,15 @@ case class Cast(
// date can't cast to decimal in Hive
(c, evPrim, evNull) => code"$evNull = true;"
case TimestampType =>
// Note that we lose precision here.
(c, evPrim, evNull) =>
code"""
Decimal $tmp = Decimal.apply(
scala.math.BigDecimal.valueOf(${timestampToDoubleCode(c)}));
Decimal $tmp = Decimal.apply($c, 19, 6);
${changePrecision(tmp, target, evPrim, evNull, canNullSafeCast, ctx)}
"""
case _: TimeType =>
(c, evPrim, evNull) =>
code"""
Decimal $tmp = Decimal.apply(
scala.math.BigDecimal.valueOf(${timeToDoubleCode(c)}));
Decimal $tmp = Decimal.apply($c, 14, 9);
${changePrecision(tmp, target, evPrim, evNull, canNullSafeCast, ctx)}
"""
case DecimalType() =>
Expand Down Expand Up @@ -1767,8 +1765,6 @@ case class Cast(
private[this] def timestampToDoubleCode(ts: ExprValue): Block =
code"$ts / (double)$MICROS_PER_SECOND"

private[this] def timeToDoubleCode(ts: ExprValue): Block =
code"$ts / (double)$NANOS_PER_SECOND"
private[this] def timeToLongCode(timeValue: ExprValue): Block =
code"Math.floorDiv($timeValue, ${NANOS_PER_SECOND}L)"

Expand Down
2 changes: 1 addition & 1 deletion ...talyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/CastWithAnsiOnSuite.scala
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -810,7 +810,7 @@ class CastWithAnsiOnSuite extends CastSuiteBase with QueryErrorsBase {
),
condition = "NUMERIC_VALUE_OUT_OF_RANGE.WITH_SUGGESTION",
parameters = Map(
"value" -> "86399.123456",
"value" -> "86399.123456000",
Copy link
Contributor

@uros-db uros-db Jul 17, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Related to the previous comment, I think that these error messages become a bit counter-intuitive for users?

Copy link
Member Author

@MaxGekk MaxGekk Jul 17, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems it is counter-intuitive independently from the scale. No doubt there is a room for error improvement. We could print the original value of the source type like TIME'23:59:59.123456' instead of 86399.123456 or maybe together.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems it is counter-intuitive independently from the scale.

This is a good argument. And yes, source type is likely the best fit here, at least from the user perspective I think.

"precision" -> "2",
"scale" -> "0",
"config" -> """"spark.sql.ansi.enabled""""
Expand Down
6 changes: 3 additions & 3 deletions sql/core/src/test/resources/sql-tests/results/cast.sql.out
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2305,7 +2305,7 @@ org.apache.spark.SparkArithmeticException
"config" : "\"spark.sql.ansi.enabled\"",
"precision" : "1",
"scale" : "0",
"value" : "60.0"
"value" : "60.000000000"
},
"queryContext" : [ {
"objectType" : "",
Expand All @@ -2330,7 +2330,7 @@ org.apache.spark.SparkArithmeticException
"config" : "\"spark.sql.ansi.enabled\"",
"precision" : "3",
"scale" : "0",
"value" : "3600.0"
"value" : "3600.000000000"
},
"queryContext" : [ {
"objectType" : "",
Expand All @@ -2355,7 +2355,7 @@ org.apache.spark.SparkArithmeticException
"config" : "\"spark.sql.ansi.enabled\"",
"precision" : "5",
"scale" : "2",
"value" : "36000.0"
"value" : "36000.000000000"
},
"queryContext" : [ {
"objectType" : "",
Expand Down