[
https://issues.apache.org/jira/browse/FLINK-39214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18120043#comment-18120043
]
suntectec commented on FLINK-39214:
-----------------------------------
Hi all,
I've been following this issue alongside a related discussion on the Paimon
side (apache/paimon#10099 and PR #10200), where the same underlying limitation
surfaces when Flink {{TIME(9)}} meets Paimon's Parquet-based storage.
I agree the core problem is the *silent truncation* — {{TIME(p)}} accepts
precision up to 9, but values beyond millisecond precision are quietly rounded
or dropped. That's a correctness issue worth addressing.
At the same time, fully supporting precision 4–9 would require changing the
internal representation from a 32-bit {{int}} to a 64-bit {{{}long{}}}, which
as noted in the issue is a fairly large cross-cutting change. Given that
{{TIMESTAMP(9)}} already covers most high-precision time needs, I wonder if a
more practical short-term step is to make the declared precision match what is
actually representable, and fail fast for unsupported precision instead of
truncating silently.
Just sharing a perspective from the Paimon side. Happy to hear what others
think.
> Support TIME type precision beyond milliseconds (precision > 3)
> ---------------------------------------------------------------
>
> Key: FLINK-39214
> URL: https://issues.apache.org/jira/browse/FLINK-39214
> Project: Flink
> Issue Type: Improvement
> Components: Table SQL / Planner
> Reporter: Ramin Gharib
> Priority: Major
>
> Currently, the TIME type internally stores time values as milliseconds-of-day
> in a 32-bit integer. This means that while TIME(p) accepts precision values
> up to 9, any fractional seconds beyond millisecond precision (i.e., precision
> > 3) are silently truncated.
> For example:
> * TIME '12:34:56.123456789' is stored as 12:34:56.123, losing the
> microsecond and nanosecond components.
> * Casting a TIME(5) value to TIMESTAMP only preserves up to 3 digits of
> fractional seconds.
> To fully support TIME(p) for precision 4–9, the internal representation would
> need to change (e.g., storing microseconds or nanoseconds in a long).
> This was identified while working on FLINK-17224, which added support for
> TIME precision up to milliseconds (precision 0–3).
>
> Affected areas:
> * CastRulesTest.java — STRING to TIME and TIME to TIMESTAMP/TIMESTAMP_LTZ
> casts truncate sub-millisecond fractions
> * CastFunctionITCase.java — STRING to TIME(0) cast truncates sub-millisecond
> fractions
> * DateTimeUtils.toInternal(LocalTime) — converts to millis, discarding
> sub-millis
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
