uros-b commented on code in PR #56407:
URL: https://github.com/apache/spark/pull/56407#discussion_r3409974405
##########
sql/core/src/main/scala/org/apache/spark/sql/execution/datasources/parquet/ParquetRowConverter.scala:
##########
@@ -484,6 +484,37 @@ private[parquet] class ParquetRowConverter(
}
}
+ // The TIMESTAMP(NANOS) parquet type postdates Spark's switch to the
proleptic Gregorian
+ // calendar, so no legacy hybrid-calendar writer could have produced it.
Nanos values are
+ // always proleptic Gregorian and are exempt from datetime rebasing
+ // (`spark.sql.parquet.datetimeRebaseModeInRead` only covers DATE,
TIMESTAMP_MILLIS and
+ // TIMESTAMP_MICROS).
+ case _: TimestampLTZNanosType
+ if
parquetType.getLogicalTypeAnnotation.isInstanceOf[TimestampLogicalTypeAnnotation]
&&
+ parquetType.getLogicalTypeAnnotation
+ .asInstanceOf[TimestampLogicalTypeAnnotation].getUnit ==
TimeUnit.NANOS =>
+ new ParquetPrimitiveConverter(updater) {
+ override def addLong(value: Long): Unit = {
+ val epochMicros = Math.floorDiv(value,
DateTimeConstants.NANOS_PER_MICROS)
+ val nanosWithinMicro =
+ Math.floorMod(value, DateTimeConstants.NANOS_PER_MICROS).toShort
+ this.updater.set(TimestampNanosVal.fromParts(epochMicros,
nanosWithinMicro))
+ }
+ }
+
Review Comment:
In ParquetRowConverter, both new cases store the value verbatim. This is
fine for the two normal paths (schema inference always mints precision 9;
Spark-written files were already truncated at literal creation). But the
converter is driven by the catalyst type, and a user can supply an explicit
read schema like spark.read.schema("ts TIMESTAMP_NTZ(7)").parquet(foreignFile)
over a foreign full-precision TIMESTAMP(NANOS) file. In that case the stored
nanosWithinMicro keeps all 9 sub-second digits, violating the invariant the
rest of the stack maintains (SparkDateTimeUtils.instantToTimestampNanos /
localDateTimeToTimestampNanos both call truncateNanosWithinMicroToPrecision).
TimestampNanosVal.fromParts only enforces [0, 999], so it won't fail — it'll
just carry sub-precision data.
The case already pattern-matches the type, so binding it (case t:
TimestampNTZNanosType if ...) and truncating to t.precision would close the gap
and mirror the canonical conversions.
--
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]
