github-actions[bot] commented on code in PR #65446:
URL: https://github.com/apache/doris/pull/65446#discussion_r3709316056
##########
be/src/format_v2/jni/hudi_jni_reader.cpp:
##########
@@ -93,6 +93,10 @@ Status
HudiJniReader::build_scanner_params(std::map<std::string, std::string>* p
(*params)["instant_time"] = hudi_params.instant_time;
(*params)["serde"] = hudi_params.serde;
(*params)["input_format"] = hudi_params.input_format;
+ (*params)["time_zone"] = _scan_params->__isset.hive_parquet_time_zone &&
Review Comment:
[P1] Keep the INT96 override off logical Hudi timestamps
This `time_zone` is not INT96-specific on the Java side:
`HadoopHudiColumnValue.getDateTime()` also applies it to every `LongWritable`
epoch-millisecond/microsecond timestamp, while Hudi maps Avro
`timestamp-micros` to `DATETIMEV2`. Native Parquet substitutes the catalog zone
only when the physical type is INT96, so an INT64 timestamp uses the session
zone natively but the catalog zone (or UTC when unset) through forced JNI/MOR;
MOR can therefore return different values across its native and JNI slices.
Please carry an encoding-aware INT96 option or preserve the query timezone for
non-INT96 JNI values, and add INT64/MOR native-versus-JNI coverage.
--
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]
