github-actions[bot] commented on code in PR #69243:
URL: https://github.com/apache/doris/pull/69243#discussion_r4308162352
##########
be/src/format/orc/vorc_reader.h:
##########
@@ -657,12 +657,12 @@ class OrcReader : public TableFormatReader, public
RowPositionProvider {
if (data->hasNulls && !data->notNull[i]) {
continue;
}
- // Check the UTC epoch before packing: ORC permits years outside
Doris's 0001-9999 range.
- static constexpr int64_t MIN_SECONDS = -62135596800LL;
+ // Check the UTC epoch before packing: ORC permits years outside
Doris's 0000-9999 range.
+ static constexpr int64_t MIN_SECONDS = -62167219200LL;
Review Comment:
[P2] Handle year-zero leap day before widening this bound
With TIMESTAMPTZ mapping enabled, a non-null ORC value with `seconds =
-62162121600` and zero nanoseconds now passes this check and becomes
`0000-02-29 00:00:00` UTC under [CCTZ's
calendar](https://github.com/google/cctz/blob/v2.5/include/cctz/civil_time_detail.h#L78-L80).
However, `doris::is_leap(0)` is false (`util/time_lut.h`), so
`DateV2Value::is_invalid()` rejects that date. When the selected value is
formatted, `DateV2Value::to_buffer()` returns length zero and
`TimestampTzValue::to_buffer()` appends only the timezone suffix: the UTC
result is silently `+00:00`. This V1 input previously failed with
`DataQualityError`. Please make year-zero calendar handling consistent through
decoding and formatting, including session-timezone conversion, and cover
February 29 with an output/round-trip test; the new first/last-day assertions
miss this case.
--
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]
