hutiefang76 opened a new issue, #12540:
URL: https://github.com/apache/seatunnel/issues/12540
### What happened
On current `dev`, DuckDB JDBC Source and Sink silently discard fractional
seconds in a `TIME` value. `00:00:00.000001` is read as `LocalTime 00:00:00`,
and writing the original `LocalTime` also stores `00:00:00`.
### Reproduction
DuckDB JDBC 1.3.1.0, current dev `7fa3412e0`, JDK 17:
```sql
CREATE TABLE main.time_precision_source (id INTEGER, value TIME);
INSERT INTO main.time_precision_source VALUES
(0, TIME '00:00:00'),
(1, TIME '00:00:00.000001'),
(2, TIME '12:34:56.123456'),
(3, TIME '23:59:59.999999'),
(4, NULL);
```
Read this table with the JDBC Source using `driver =
"org.duckdb.DuckDBDriver"` and `table_path = "main.time_precision_source"`.
Compare each emitted value with the SQL value. Separately write the original
`LocalTime` values through the JDBC Sink into another `TIME` table and read it
back with a new JDBC connection.
The one-microsecond value becomes midnight in both paths. SQL NULL remains
NULL. The inherited DuckDB row converter uses `java.sql.Time` on reads and
writes, losing the fraction. The driver can bind `LocalTime` directly; its
typed LocalTime read is unsupported in 1.3.1, so the existing JDBC helper's
textual fallback is needed.
### Expected
Preserve DuckDB TIME microseconds in Source and Sink independently of the
JVM default timezone. This concerns timezone-free TIME values, not TIMETZ or
timestamp conversion.
I have a focused DuckDB-only fix with separate real Source and Sink
regressions. Both regressions fail before the patch; the fix passes JDK 8/17
and UTC, Asia/Shanghai and America/New_York controls.
--
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]
