zhang-arvin commented on issue #10099: URL: https://github.com/apache/paimon/issues/10099#issuecomment-5845650128
PR opened: https://github.com/apache/paimon/pull/10200 Verdict on the two options in the report: this is case (b), not (a). `TIME` is physically milliseconds-of-the-day in an `int` across the whole stack - the internal row representation, `RowCompactedSerializer`, and the Parquet `TIME_MILLIS` logical type - so microseconds/nanoseconds are not representable without changing the storage format and the Parquet type of existing tables. `TimeType` nevertheless declared `MAX_PRECISION = 9` and promised nanosecond precision via a `long`. The actual defect is therefore the silent part: `TIME(7)` was accepted and then narrowed to milliseconds, and `DateTimeUtils.parseFraction` rounds on the 4th fractional digit, so `12:34:56.1234567` came back as `12:34:56.124` - larger than the input - with no error. The PR caps the declared precision at what is actually representable so the declaration fails fast, and corrects the Javadoc that advertised the nanosecond range. Local: `DataTypesTest` 27 tests and `SchemaMergingUtilsTest` 17 tests, 0 failures. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
