+1 for this
Best regards, Sergey On Mon, Mar 2, 2026, 03:07 Leonard Xu <[email protected]> wrote: > +1 for the data correctness bugfix, looks like we missed the precision for > TIME type in many places after went through your PR. > > Best, > Leonard > > > > 2026 2月 27 22:24，Timo Walther <[email protected]> 写道： > > > > Hi Ramin, > > > > Thank you for working on this. It is a pity that we didn't fix this > earlier. Somehow, this behavior is a historical artifact from the Blink > merge. The current behavior is confusing and simply wrong. We should fix > issues that lead to data loss. Fortunately, the TIME type is not used > often, as most pipelines use TIMESTAMP types. > > > > +1 for this breaking change, as it is a valid bug fix. > > > > Thanks, > > Timo > > > > On 26.02.26 15:23, Ramin Gharib wrote: > >> Hi everyone, > >> I'd like to open a discussion regarding an issue we have where time > >> precision is not working properly, which requires some code updates to > >> resolve. > >> I am tracking this under the following Jira ticket [1]. > >> When setting a column type to a specific precision, such as TIME(2), the > >> schema incorrectly registers it as TIME(0). Consequently, the returned > >> values suffer from data loss. For example, if a user runs the following: > >> - CREATE TABLE test_sql_time2 (val TIME(2)); > >> - INSERT INTO test_sql_time2 VALUES (TIME '14:30:00.12'); > >> Selecting the value returns 14:30:00 instead of the expected > 14:30:00.12. > >> Furthermore, running DESCRIBE test_sql_time2; confirms that the Data > Type > >> is incorrectly set to TIME(0). > >> To fix this, I have updated the code to ensure the time precision is > >> handled and maintained correctly. I have opened a pull request with the > >> implementation [2]. > >> Please note that fixing this introduces a change in behavior. Because > >> precision will now be respected, existing pipelines that unknowingly > relied > >> on the data being implicitly truncated to TIME(0) will start retaining > >> their fractional precision. I would like to get the community's > thoughts on > >> whether we need to treat this as a formal breaking change, and if we > should > >> consider any specific backward-compatibility or migration steps. > >> I would appreciate it if anyone interested could take a look at the > >> Jira/PR, review the proposed changes, and share any feedback or > thoughts on > >> the approach. > >> Looking forward to hearing from you. > >> Best regards, > >> Ramin Gharib > >> [1] https://issues.apache.org/jira/browse/FLINK-17224 > >> [2] https://github.com/apache/flink/pull/26954 > > > >
