[
https://issues.apache.org/jira/browse/FLINK-39214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramin Gharib updated FLINK-39214:
---------------------------------
Description:
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
was:
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
> 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)
