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
