-
Notifications
You must be signed in to change notification settings - Fork 59
Open
Description
I found when running FROM test_all_types() the following exception was raised
Execution error (DateTimeException) at java.time.temporal.ValueRange/checkValidValue (ValueRange.java:319).
Invalid value for NanoOfDay (valid values 0 - 86399999999999): 86400000000000
java.time.temporal.ValueRange/checkValidValue (ValueRange.java:319)
java.time.temporal.ChronoField/checkValidValue (ChronoField.java:721)
java.time.LocalTime/ofNanoOfDay (LocalTime.java:410)
org.duckdb.DuckDBVector/getLocalTime (DuckDBVector.java:137)
org.duckdb.DuckDBVector/getObject (DuckDBVector.java:96)
org.duckdb.DuckDBResultSet/getObject (DuckDBResultSet.java:168)
[OMITTED APPLICATION FRAMES]
[...]
After looking at the results of SELECT time FROM test_all_types();
| time |
|---|
| 00:00:00 |
| 24:00:00 |
| NULL |
and looking at the ISO 8601 wikipedia page it looks like the ISO 8601 standard has thrashed a little bit on if 24 is a valid value for an hour.
According to the LocalTime.ofNanoOfDay(long) docs the valid range is from 0 to 24 * 60 * 60 * 1,000,000,000 - 1 which is the source of the exception being raised. I'm unfamiliar with alternative Java APIs that would conform to the current state of the 8601 spec that does allow 24 for an hour value.
Here is a test case that I think should exercise the issue with the java.time.LocalTime#onNanoOfDay(long) implementation.
public class TestTimestamp {
public static void test_duckdb_time_boundaries() throws Exception {
try (Connection conn = DriverManager.getConnection(JDBC_URL); Statement stmt = conn.createStatement()) {
try (ResultSet rs = stmt.executeQuery("SELECT '00:00:00'::TIME, '24:00:00'::TIME")) {
rs.next();
assertEquals(rs.getTime(0), 0, "floor");
assertEquals(rs.getTime(1), 86400000000000, "ceil");
}
}
}
}Metadata
Metadata
Assignees
Labels
No labels