[
https://issues.apache.org/jira/browse/FLINK-39666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated FLINK-39666:
-----------------------------------
Labels: pull-request-available (was: )
> Fix TO_TIMESTAMP_LTZ multiple edge-case bugs in precision handling
> ------------------------------------------------------------------
>
> Key: FLINK-39666
> URL: https://issues.apache.org/jira/browse/FLINK-39666
> Project: Flink
> Issue Type: Bug
> Components: Table SQL / API, Table SQL / Planner
> Reporter: Ramin Gharib
> Priority: Major
> Labels: pull-request-available
>
> Follow-up review of FLINK-39244 uncovered five bugs. All are reproducible on
> master at \{{25493ac2a95}}.
> h2. 1. \{{toTimestampData(double, int)}} overflows near year 9999
> The range check on \{{epoch / 10^precision}} passes, then \{{(long) (epoch *
> 10^(9 - precision))}} saturates.
> {code:java}
> DateTimeUtils.toTimestampData(253402300799.0, 0)
> // expected: 9999-12-31T23:59:59Z
> // actual: 2262-04-11T23:47:16.854775807Z
> {code}
> h2. 2. \{{epochToTimestampData}} does not validate precision
> Negative precision makes \{{Math.floorDiv}} throw \{{ArithmeticException: /
> by zero}}. Precision > 9 silently returns \{{1970-01-01T00:00:00Z}}.
> Expected: return \{{null}} for precision outside \{{[0, 9]}}.
> h2. 3. \{{precisionFromFormat}} only counts trailing \{{'S'}} characters
> {code:java}
> DateTimeUtils.precisionFromFormat("yyyy-MM-dd HH:mm:ss.SSSSSS X"); //
> returns 3, expected 6
> DateTimeUtils.precisionFromFormat("yyyy-MM-dd HH:mm:ss.SSSS'Z'"); //
> returns 3, expected 4
> {code}
> The method should detect the \{{S}} run inside the pattern, ignoring quoted
> sections.
> h2. 4. \{{ValueLiteralExpression.canRepresentAsLong}} off-by-one
> The check ignores the nanos term \{{toEpochValue}} adds. At \{{epochSeconds
> == 9223372036}} and precision 9, any \{{nanos > 854_775_807}} overflows and
> emits a wrapped negative literal.
> {code:java}
> new ValueLiteralExpression(
> Instant.ofEpochSecond(9223372036L, 900_000_000),
> DataTypes.TIMESTAMP_LTZ(9).notNull())
> .asSerializableString(DefaultSqlFactory.INSTANCE);
> // expected: TO_TIMESTAMP_LTZ('2262-04-11 23:47:16.900000000', 'yyyy-MM-dd
> HH:mm:ss.SSSSSSSSS', 'UTC')
> // actual: TO_TIMESTAMP_LTZ(-9223372036809551616, 9)
> {code}
> h2. 5. Non-literal precision bypasses \{{validatePrecision}}
> {\{ToTimestampLtzTypeStrategy.validatePrecision}} only fires when the
> precision argument is a literal. For a column-valued precision, validation is
> skipped and the raw row value reaches the runtime, triggering issue 2.
> {code:sql}
> SELECT TO_TIMESTAMP_LTZ(epoch, prec) FROM t -- prec = -1 throws, prec = 10
> returns epoch 0
> {code}
> h2. Test coverage
> Failing tests for all five issues exist locally:
> * New \{{DateTimeUtilsTest}} and an added case in
> \{{ExpressionTest#testTimestampLtzPrecisionAsSerializableString}} in
> \{{flink-table-common}}.
> * Two new \{{TestSetSpec}} blocks in
> \{{TimeFunctionsITCase#toTimestampLtzTestCases}} in \{{flink-table-planner}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
