Skip to content

Commit e36851e

Browse files
committed
fix
1 parent 950d33a commit e36851e

File tree

2 files changed

+9
-5
lines changed

2 files changed

+9
-5
lines changed

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/datetimeExpressions.scala

Lines changed: 0 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1225,8 +1225,6 @@ private[spark] case class TimestampTimezoneCorrection(
12251225
to: Expression)
12261226
extends TernaryExpression with ImplicitCastInputTypes {
12271227

1228-
// modeled on ToUTCTimestamp + Conv (as an example TernaryExpression)
1229-
12301228
// convertTz() does the *opposite* conversion we want, which is why from & to appear reversed
12311229
// in all the calls to convertTz. Its used for showing how the display time changes when we go
12321230
// from one timezone to another. We want to see how should change the SQLTimestamp value to

sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/DateExpressionsSuite.scala

Lines changed: 9 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -742,7 +742,7 @@ class DateExpressionsSuite extends SparkFunSuite with ExpressionEvalHelper {
742742
test(null, null, null)
743743
}
744744

745-
test("parquet_timestamp_correction") {
745+
test("timestamp_timezone_correction") {
746746
def test(t: String, fromTz: String, toTz: String, expected: String): Unit = {
747747
checkEvaluation(
748748
TimestampTimezoneCorrection(
@@ -757,8 +757,14 @@ class DateExpressionsSuite extends SparkFunSuite with ExpressionEvalHelper {
757757
NonFoldableLiteral.create(toTz, StringType)),
758758
if (expected != null) Timestamp.valueOf(expected) else null)
759759
}
760-
test("2015-07-24 00:00:00", "UTC", "PST", "2015-07-23 17:00:00")
761-
test("2015-01-24 00:00:00", "UTC", "PST", "2015-01-23 16:00:00")
760+
// These conversions may look backwards -- but this is *NOT* saying:
761+
// when the clock says 2015-07-24 00:00:00 in PST, what would it say to somebody in UTC?
762+
// Instead, its saying -- suppose somebody stored "2015-07-24 00:00:00" while in PST, but
763+
// as millis-since-epoch. What millis-since-epoch would I need to also see
764+
// "2015-07-24 00:00:00" if my clock were in UTC? Just for testing convenience, we input
765+
// that last value as "what would my clock in PST say for that final millis-since-epoch?"
766+
test("2015-07-24 00:00:00", "PST", "UTC", "2015-07-23 17:00:00")
767+
test("2015-01-24 00:00:00", "PST", "UTC", "2015-01-23 16:00:00")
762768
test(null, "UTC", "UTC", null)
763769
test("2015-07-24 00:00:00", null, null, null)
764770
test(null, null, null, null)

0 commit comments

Comments
 (0)