DateTimeException: Invalid value for NanoOfDay raised when running test_all_types()
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 35/100
Research direction
Start with org.duckdb.DuckDBVector.getLocalTime and getObject, where the stack trace shows the failing conversion, then review the TestTimestamp boundary case in the issue. Check how SELECT TIME values 00:00:00, 24:00:00, and NULL are returned through JDBC. Done means the boundary test no longer raises DateTimeException and verifies the intended floor and ceiling behavior.
Written by the indexing model from the issue text.
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");
}
}
}
}
- Dominant language
- C++
- Stars
- 127
- Forks
- 80
- Avg merge
- 13h 41m
- Merged PRs (30d)
- 44
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from duckdb/duckdb-java
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
duckdb/duckdb-java#832 · 2 comments ·
-
Native SIGSEGV in DuckDB JDBC when repeatedly executing queries with window functions and LIMIT 0 Open
Difficulty 4/5 3-5 days Newbie friendliness 48/100
duckdb/duckdb-java#871 · 4 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
duckdb/duckdb-java#872 ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
duckdb/duckdb-java#837 ·
-
executeBatch()` on a prepared INSERT runs s are ~1–2 orders of magnitude slower than the Appender Open
Difficulty 5/5 Over a week Newbie friendliness 42/100
duckdb/duckdb-java#815 · 1 comment ·
All issues in duckdb/duckdb-java
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
AXERA-TECH/ax-llm#77 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
games-on-whales/wolf#509 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
bug-unconfirmed
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
NVIDIA/cuda-samples#453 ·