You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@spark.apache.org by "iRakson (via GitHub)" <gi...@apache.org> on 2026/07/05 11:39:32 UTC
[PR] [SPARK-57818][SQL]Support nanosecond-precision and LTZ timestamps in convert_timezone [spark]
iRakson opened a new pull request, #57008:
URL: https://github.com/apache/spark/pull/57008
### What changes were proposed in this pull request?
Extends ConvertTimezone (convert_timezone()) to accept nanosecond-precision timestamps (TIMESTAMP_NTZ(p), p in [7, 9]) as input, alongside the existing microsecond TimestampType inputs. ConvertTimezone would returns a nanosecond NTZ value at the same precision with the remainder preserved in case of TIMESTAMP_NTZ(p). Existing microsecond computation won't be affected by this change.
### Why are the changes needed?
ConvertTimezone types its source as TimestampNTZType only and returns TimestampNTZType, using convertTimestampNtzToAnotherTz(Long, ...). It rejects all nanosecond timestamp types. We should allow TIMESTAMP_NTZ(p).
### Does this PR introduce _any_ user-facing change?
Yes, convert_timezone function would accept TIMESTAMP_NTZ(p) and return NTZ value at same precision with remainder preserved.
### How was this patch tested?
Added unit tests in DateExpressionsSuite.scala and also generated golden files.
### Was this patch authored or co-authored using generative AI tooling?
Used claude code for writing UTs and generating golden files.
--
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: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
Re: [PR] [SPARK-57818][SQL]Support nanosecond-precision and LTZ timestamps in convert_timezone [spark]
Posted by "iRakson (via GitHub)" <gi...@apache.org>.
iRakson commented on PR #57008:
URL: https://github.com/apache/spark/pull/57008#issuecomment-4956564911
@cloud-fan Please review
--
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: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
Re: [PR] [SPARK-57818][SQL]Support nanosecond-precision and LTZ timestamps in convert_timezone [spark]
Posted by "cloud-fan (via GitHub)" <gi...@apache.org>.
cloud-fan commented on code in PR #57008:
URL: https://github.com/apache/spark/pull/57008#discussion_r3573411484
##########
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/datetimeExpressions.scala:
##########
@@ -4281,20 +4281,55 @@ case class ConvertTimezone(
Seq(
StringTypeWithCollation(supportsTrimCollation = true),
StringTypeWithCollation(supportsTrimCollation = true),
- TimestampNTZType)
- override def dataType: DataType = TimestampNTZType
+ TypeCollection(TimestampNTZType, AnyTimestampNanoType))
Review Comment:
Non-blocking (message-only): the wrong-type error advertises `TIMESTAMP_LTZ(P)` as an acceptable source, but the guard just below rejects LTZ nanos. When the source is a wholly-invalid type (e.g. an int), the mismatch comes from the generic `super.checkInputDataTypes()` over this `TypeCollection`, whose `requiredType` renders as `"(TIMESTAMP_NTZ OR (TIMESTAMP_LTZ(P) OR TIMESTAMP_NTZ(P) WITH P IN [7, 9]))"` — because `AnyTimestampNanoType.simpleString` lists `timestamp_ltz(p)`. That's the opposite of the `checkInputDataTypes` guard's own (correctly narrowed) `requiredType`, so the two error paths disagree on whether LTZ is accepted. No wrong result, and there's no clean one-liner fix (it needs a custom message or a narrower `AbstractDataType`), so just flagging it.
--
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: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
Re: [PR] [SPARK-57818][SQL]Support nanosecond-precision and LTZ timestamps in convert_timezone [spark]
Posted by "iRakson (via GitHub)" <gi...@apache.org>.
iRakson commented on PR #57008:
URL: https://github.com/apache/spark/pull/57008#issuecomment-5333719110
@cloud-fan Please review.
--
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: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
Re: [PR] [SPARK-57818][SQL]Support nanosecond-precision and LTZ timestamps in convert_timezone [spark]
Posted by "iRakson (via GitHub)" <gi...@apache.org>.
iRakson commented on PR #57008:
URL: https://github.com/apache/spark/pull/57008#issuecomment-4892623286
@MaxGekk Please review
--
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: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
Re: [PR] [SPARK-57818][SQL] Support nanosecond-precision NTZ timestamps in convert_timezone [spark]
Posted by "cloud-fan (via GitHub)" <gi...@apache.org>.
cloud-fan commented on PR #57008:
URL: https://github.com/apache/spark/pull/57008#issuecomment-5346022975
the test timeout issue is unrelated, thanks, merging to master/4.x!
--
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: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
Re: [PR] [SPARK-57818][SQL] Support nanosecond-precision NTZ timestamps in convert_timezone [spark]
Posted by "cloud-fan (via GitHub)" <gi...@apache.org>.
cloud-fan commented on PR #57008:
URL: https://github.com/apache/spark/pull/57008#issuecomment-5346039393
**Merge Summary:**
- merged into master https://github.com/apache/spark/commit/31f5f5abb8d7ba5b75338df6e9810ee8677d3ff1
- merged into branch-4.x https://github.com/apache/spark/commit/add4a915f951db09af7bf820cdadd6e15cbdc224
*Posted by `merge_spark_pr.py`*
--
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: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
Re: [PR] [SPARK-57818][SQL] Support nanosecond-precision NTZ timestamps in convert_timezone [spark]
Posted by "cloud-fan (via GitHub)" <gi...@apache.org>.
cloud-fan closed pull request #57008: [SPARK-57818][SQL] Support nanosecond-precision NTZ timestamps in convert_timezone
URL: https://github.com/apache/spark/pull/57008
--
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: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org
Re: [PR] [SPARK-57818][SQL]Support nanosecond-precision and LTZ timestamps in convert_timezone [spark]
Posted by "cloud-fan (via GitHub)" <gi...@apache.org>.
cloud-fan commented on code in PR #57008:
URL: https://github.com/apache/spark/pull/57008#discussion_r3812021829
##########
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/datetimeExpressions.scala:
##########
@@ -4281,20 +4281,64 @@ case class ConvertTimezone(
Seq(
StringTypeWithCollation(supportsTrimCollation = true),
StringTypeWithCollation(supportsTrimCollation = true),
- TimestampNTZType)
- override def dataType: DataType = TimestampNTZType
-
- override def nullSafeEval(srcTz: Any, tgtTz: Any, micros: Any): Any = {
- DateTimeUtils.convertTimestampNtzToAnotherTz(
+ TypeCollection(TimestampNTZType, AnyTimestampNanoType))
+
+ // sourceTs's requiredType, as actually enforced by this method: TypeCollection includes
+ // AnyTimestampNanoType (rather than an NTZ-only nanos type) only so that a LTZ(p) input is
Review Comment:
**Nit:**
```suggestion
// AnyTimestampNanoType (rather than an NTZ-only nanos type) only so that an LTZ(p) input is
```
##########
sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/DateExpressionsSuite.scala:
##########
@@ -2210,6 +2210,104 @@ class DateExpressionsSuite extends SparkFunSuite with ExpressionEvalHelper {
}
}
+ test("SPARK-57818: convert_timezone over nanosecond-precision timestamps") {
+ val ntzType9 = TimestampNTZNanosType(9)
+
+ // The nanosWithinMicro remainder is carried through unchanged by a zone conversion; only the
+ // whole-microsecond part shifts with the zone offset.
+ val srcNanos = DateTimeUtils.localDateTimeToTimestampNanos(
+ LocalDateTime.parse("2022-03-27T03:00:00.123456789"), 9)
+ val expectedNanos = DateTimeUtils.localDateTimeToTimestampNanos(
+ LocalDateTime.parse("2022-03-27T04:00:00.123456789"), 9)
+ assert(srcNanos.nanosWithinMicro == expectedNanos.nanosWithinMicro)
+ checkEvaluation(
+ ConvertTimezone(
+ Literal("Europe/Brussels"),
+ Literal("Europe/Moscow"),
+ Literal.create(srcNanos, ntzType9)),
+ expectedNanos)
+
+ // Pre-epoch values exercise the negative-epoch path. The expected epochMicros is derived from
+ // the already-verified micros-only conversion (SPARK-37552 tests that path); this only checks
+ // that the nanos wiring delegates to it correctly and carries the remainder through unchanged.
+ val preEpochSrc = DateTimeUtils.localDateTimeToTimestampNanos(
+ LocalDateTime.parse("1960-01-01T00:00:00.000000001"), 9)
+ val preEpochExpectedMicros = DateTimeUtils.convertTimestampNtzToAnotherTz(
+ "Europe/Moscow", "Europe/Brussels", preEpochSrc.epochMicros)
+ checkEvaluation(
+ ConvertTimezone(
+ Literal("Europe/Moscow"),
+ Literal("Europe/Brussels"),
+ Literal.create(preEpochSrc, ntzType9)),
+ TimestampNanosVal.fromParts(preEpochExpectedMicros, preEpochSrc.nanosWithinMicro))
+
+ // Precision (7/8/9) is preserved on the result; AnyTimestampNanoType.defaultConcreteType
+ // would incorrectly always widen it to 9.
+ Seq(7, 8, 9).foreach { precision =>
+ val ntzType = TimestampNTZNanosType(precision)
+ val src = DateTimeUtils.localDateTimeToTimestampNanos(
+ LocalDateTime.parse("2022-03-27T03:00:00.123456789"), precision)
+ val convertExpr = ConvertTimezone(
+ Literal("Europe/Brussels"), Literal("Europe/Moscow"), Literal.create(src, ntzType))
+ assert(convertExpr.dataType === ntzType)
+ }
+
+ // LTZ(p) nanos values are rejected: this function is NTZ-only, matching the existing
+ // TimestampNTZType-only micro path. Unlike that micro path -- which does implicit-cast a
Review Comment:
**Nit:**
```suggestion
// TimestampNTZType-only micro path. Unlike that micro path -- which implicitly casts a
```
##########
sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/DateExpressionsSuite.scala:
##########
@@ -2210,6 +2210,104 @@ class DateExpressionsSuite extends SparkFunSuite with ExpressionEvalHelper {
}
}
+ test("SPARK-57818: convert_timezone over nanosecond-precision timestamps") {
+ val ntzType9 = TimestampNTZNanosType(9)
+
+ // The nanosWithinMicro remainder is carried through unchanged by a zone conversion; only the
+ // whole-microsecond part shifts with the zone offset.
+ val srcNanos = DateTimeUtils.localDateTimeToTimestampNanos(
+ LocalDateTime.parse("2022-03-27T03:00:00.123456789"), 9)
+ val expectedNanos = DateTimeUtils.localDateTimeToTimestampNanos(
+ LocalDateTime.parse("2022-03-27T04:00:00.123456789"), 9)
+ assert(srcNanos.nanosWithinMicro == expectedNanos.nanosWithinMicro)
+ checkEvaluation(
+ ConvertTimezone(
+ Literal("Europe/Brussels"),
+ Literal("Europe/Moscow"),
+ Literal.create(srcNanos, ntzType9)),
+ expectedNanos)
+
+ // Pre-epoch values exercise the negative-epoch path. The expected epochMicros is derived from
+ // the already-verified micros-only conversion (SPARK-37552 tests that path); this only checks
+ // that the nanos wiring delegates to it correctly and carries the remainder through unchanged.
+ val preEpochSrc = DateTimeUtils.localDateTimeToTimestampNanos(
+ LocalDateTime.parse("1960-01-01T00:00:00.000000001"), 9)
+ val preEpochExpectedMicros = DateTimeUtils.convertTimestampNtzToAnotherTz(
+ "Europe/Moscow", "Europe/Brussels", preEpochSrc.epochMicros)
+ checkEvaluation(
+ ConvertTimezone(
+ Literal("Europe/Moscow"),
+ Literal("Europe/Brussels"),
+ Literal.create(preEpochSrc, ntzType9)),
+ TimestampNanosVal.fromParts(preEpochExpectedMicros, preEpochSrc.nanosWithinMicro))
+
+ // Precision (7/8/9) is preserved on the result; AnyTimestampNanoType.defaultConcreteType
+ // would incorrectly always widen it to 9.
+ Seq(7, 8, 9).foreach { precision =>
+ val ntzType = TimestampNTZNanosType(precision)
+ val src = DateTimeUtils.localDateTimeToTimestampNanos(
+ LocalDateTime.parse("2022-03-27T03:00:00.123456789"), precision)
+ val convertExpr = ConvertTimezone(
+ Literal("Europe/Brussels"), Literal("Europe/Moscow"), Literal.create(src, ntzType))
+ assert(convertExpr.dataType === ntzType)
+ }
+
+ // LTZ(p) nanos values are rejected: this function is NTZ-only, matching the existing
+ // TimestampNTZType-only micro path. Unlike that micro path -- which does implicit-cast a
+ // plain LTZ TimestampType argument down to TimestampNTZType -- a nanos source must not be
+ // silently reinterpreted from LTZ to NTZ, since that would drop the source time zone
+ // information without the user asking for it.
+ val ltzNanos = DateTimeUtils.instantToTimestampNanos(Instant.parse("2022-03-27T03:00:00Z"), 9)
+ val ltzMismatch = ConvertTimezone(
+ Literal("Europe/Brussels"), Literal("Europe/Moscow"),
+ Literal.create(ltzNanos, TimestampLTZNanosType(9)))
+ .checkInputDataTypes().asInstanceOf[DataTypeMismatch]
+ assert(ltzMismatch.errorSubClass == "UNEXPECTED_INPUT_TYPE")
+
+ // A wholly-invalid source type (not any kind of timestamp) hits the generic type check
Review Comment:
**Nit:**
```suggestion
// A wholly invalid source type (not any kind of timestamp) hits the generic type check
```
##########
sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/DateExpressionsSuite.scala:
##########
@@ -2210,6 +2210,104 @@ class DateExpressionsSuite extends SparkFunSuite with ExpressionEvalHelper {
}
}
+ test("SPARK-57818: convert_timezone over nanosecond-precision timestamps") {
+ val ntzType9 = TimestampNTZNanosType(9)
+
+ // The nanosWithinMicro remainder is carried through unchanged by a zone conversion; only the
+ // whole-microsecond part shifts with the zone offset.
+ val srcNanos = DateTimeUtils.localDateTimeToTimestampNanos(
+ LocalDateTime.parse("2022-03-27T03:00:00.123456789"), 9)
+ val expectedNanos = DateTimeUtils.localDateTimeToTimestampNanos(
+ LocalDateTime.parse("2022-03-27T04:00:00.123456789"), 9)
+ assert(srcNanos.nanosWithinMicro == expectedNanos.nanosWithinMicro)
+ checkEvaluation(
+ ConvertTimezone(
+ Literal("Europe/Brussels"),
+ Literal("Europe/Moscow"),
+ Literal.create(srcNanos, ntzType9)),
+ expectedNanos)
+
+ // Pre-epoch values exercise the negative-epoch path. The expected epochMicros is derived from
+ // the already-verified micros-only conversion (SPARK-37552 tests that path); this only checks
+ // that the nanos wiring delegates to it correctly and carries the remainder through unchanged.
+ val preEpochSrc = DateTimeUtils.localDateTimeToTimestampNanos(
+ LocalDateTime.parse("1960-01-01T00:00:00.000000001"), 9)
+ val preEpochExpectedMicros = DateTimeUtils.convertTimestampNtzToAnotherTz(
+ "Europe/Moscow", "Europe/Brussels", preEpochSrc.epochMicros)
+ checkEvaluation(
+ ConvertTimezone(
+ Literal("Europe/Moscow"),
+ Literal("Europe/Brussels"),
+ Literal.create(preEpochSrc, ntzType9)),
+ TimestampNanosVal.fromParts(preEpochExpectedMicros, preEpochSrc.nanosWithinMicro))
+
+ // Precision (7/8/9) is preserved on the result; AnyTimestampNanoType.defaultConcreteType
+ // would incorrectly always widen it to 9.
+ Seq(7, 8, 9).foreach { precision =>
+ val ntzType = TimestampNTZNanosType(precision)
+ val src = DateTimeUtils.localDateTimeToTimestampNanos(
+ LocalDateTime.parse("2022-03-27T03:00:00.123456789"), precision)
+ val convertExpr = ConvertTimezone(
+ Literal("Europe/Brussels"), Literal("Europe/Moscow"), Literal.create(src, ntzType))
+ assert(convertExpr.dataType === ntzType)
+ }
+
+ // LTZ(p) nanos values are rejected: this function is NTZ-only, matching the existing
+ // TimestampNTZType-only micro path. Unlike that micro path -- which does implicit-cast a
+ // plain LTZ TimestampType argument down to TimestampNTZType -- a nanos source must not be
+ // silently reinterpreted from LTZ to NTZ, since that would drop the source time zone
+ // information without the user asking for it.
+ val ltzNanos = DateTimeUtils.instantToTimestampNanos(Instant.parse("2022-03-27T03:00:00Z"), 9)
+ val ltzMismatch = ConvertTimezone(
+ Literal("Europe/Brussels"), Literal("Europe/Moscow"),
+ Literal.create(ltzNanos, TimestampLTZNanosType(9)))
+ .checkInputDataTypes().asInstanceOf[DataTypeMismatch]
+ assert(ltzMismatch.errorSubClass == "UNEXPECTED_INPUT_TYPE")
+
+ // A wholly-invalid source type (not any kind of timestamp) hits the generic type check
+ // instead of the explicit LTZ guard above; both paths must report the same requiredType,
+ // since neither actually accepts a LTZ(p) source.
Review Comment:
**Nit:**
```suggestion
// since neither actually accepts an LTZ(p) source.
```
##########
sql/core/src/test/resources/sql-tests/inputs/timestamp-ntz-nanos.sql:
##########
@@ -150,6 +150,21 @@ SELECT TIMESTAMP_NTZ '1960-01-02 03:04:05.123456789' + INTERVAL '0 00:00:00.0000
SELECT TIMESTAMP_NTZ '2020-01-02 03:04:05.123456789' + make_interval(0, 1, 0, 2, 0, 0, 0);
SELECT TIMESTAMP_NTZ '2020-01-02 03:04:05.123456789' + INTERVAL '1' MONTH;
+-- SPARK-57818: convert_timezone over nanosecond-precision TIMESTAMP_NTZ. The sub-microsecond
+-- remainder is carried through unchanged; only the whole-microsecond part shifts with the zone
+-- offset, and the result keeps the source's exact precision.
+SELECT convert_timezone('Europe/Brussels', 'Europe/Moscow',
+ TIMESTAMP_NTZ '2022-03-27 03:00:00.123456789');
+SELECT typeof(convert_timezone('Europe/Brussels', 'Europe/Moscow',
+ '2022-03-27 03:00:00.1234567' :: timestamp_ntz(7)));
+-- NULL nanosecond timestamp.
+SELECT convert_timezone('America/Los_Angeles', 'UTC', CAST(NULL AS timestamp_ntz(9)));
+-- convert_timezone is NTZ-only; a nanosecond LTZ(p) source is rejected rather than silently
+-- reinterpreted, unlike the microsecond path, which does implicit-cast a plain LTZ TimestampType
+-- argument down to TIMESTAMP_NTZ.
+SELECT convert_timezone('Europe/Brussels', 'Europe/Moscow',
+ '2022-03-27 03:00:00.123456789 UTC' :: timestamp_ltz(9));
Review Comment:
**Non-blocking:**
This exact rejection case is also added to `timestamp-ltz-nanos.sql`, so it generates duplicate analyzer and execution goldens. Please keep it in the LTZ suite and let this suite focus on the positive NTZ paths.
##########
sql/core/src/test/resources/sql-tests/inputs/timestamp-ntz-nanos.sql:
##########
@@ -150,6 +150,21 @@ SELECT TIMESTAMP_NTZ '1960-01-02 03:04:05.123456789' + INTERVAL '0 00:00:00.0000
SELECT TIMESTAMP_NTZ '2020-01-02 03:04:05.123456789' + make_interval(0, 1, 0, 2, 0, 0, 0);
SELECT TIMESTAMP_NTZ '2020-01-02 03:04:05.123456789' + INTERVAL '1' MONTH;
+-- SPARK-57818: convert_timezone over nanosecond-precision TIMESTAMP_NTZ. The sub-microsecond
+-- remainder is carried through unchanged; only the whole-microsecond part shifts with the zone
+-- offset, and the result keeps the source's exact precision.
+SELECT convert_timezone('Europe/Brussels', 'Europe/Moscow',
+ TIMESTAMP_NTZ '2022-03-27 03:00:00.123456789');
+SELECT typeof(convert_timezone('Europe/Brussels', 'Europe/Moscow',
+ '2022-03-27 03:00:00.1234567' :: timestamp_ntz(7)));
+-- NULL nanosecond timestamp.
+SELECT convert_timezone('America/Los_Angeles', 'UTC', CAST(NULL AS timestamp_ntz(9)));
+-- convert_timezone is NTZ-only; a nanosecond LTZ(p) source is rejected rather than silently
+-- reinterpreted, unlike the microsecond path, which does implicit-cast a plain LTZ TimestampType
Review Comment:
**Nit:**
```suggestion
-- reinterpreted, unlike the microsecond path, which implicitly casts a plain LTZ TimestampType
```
--
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: reviews-unsubscribe@spark.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org