[ 
https://issues.apache.org/jira/browse/FLINK-39214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ramin Gharib reassigned FLINK-39214:
------------------------------------

    Assignee: Ramin Gharib

> 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
>            Assignee: 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)

Reply via email to