bindings: Decimal SQL parameters keep every digit, datetime/date parameters bind, datetimes keep microseconds (#58) - #59
Merged
Conversation
Author
|
On hold, not to merge on green. Passing a Python Engine side filed as ArcadeData#8885 (a one-line |
…meters bind, datetimes keep microseconds (#58) - Positional SQL parameters: Decimal, date, and datetime go through convert_python_to_java. Left to JPype, a Decimal reached the engine as a Double (38 digits stored as 1.2345678901234567E+19, and a lookup by the same Decimal missed the exact rows), and a date or datetime matched no overload. - A datetime converts to the UTC LocalDateTime of its instant, with its microseconds. The java.util.Date it used to build kept milliseconds, so DATETIME_MICROS and DATETIME_NANOS lost the rest and never matched their own value. The instant is unchanged: a naive value is still local time, as datetime.timestamp() reads it. - Tests that fail on the previous wheel: test_decimal_parameter_keeps_every_digit, test_datetime_and_date_parameters. Full suite 491 passed, 3 skipped; bandit clean. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WWcDr7TwvcfMsQkeYQVHZr
…t passes on a UTC host (#58) On a UTC machine the naive and the aware datetime are the same instant, so a lookup by either finds all four rows; CI runs in UTC and failed on every platform. The expected rows are now those whose instant equals the value's. Passes under TZ=UTC, Asia/Seoul, and America/New_York; full suite under UTC: 491 passed, 3 skipped. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WWcDr7TwvcfMsQkeYQVHZr
…ed on every host (#58) The engine stores DATETIME as a UTC wall clock whatever the JVM's or the database's time zone (a LocalDateTime 12:34, an Instant 12:34Z and the string '12:34' all store 12:34Z, measured under TZ=UTC and Asia/Seoul with the database zone set to Asia/Seoul). A naive datetime was read as local time, so 12:34 written on a UTC+9 host read back as 03:34. It is now that wall clock as it stands; an aware datetime is still converted to UTC and keeps its instant. The test writes a naive 12:34:56.789123 and an aware 21:34:56.789123+09:00 through set() and a parameter, and checks that all four read back as the naive value with epoch 12:34:56.789Z and that a lookup by either finds all four. It fails on the previous code under TZ=Asia/Seoul (12:34 read back as 03:34) and passes on this one under UTC, Asia/Seoul and America/New_York; the full suite passes under UTC and Asia/Seoul (491 passed, 3 skipped). Docs: the type-conversion notes state the rule, and the examples that store the current time use datetime.now(timezone.utc). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WWcDr7TwvcfMsQkeYQVHZr
tae898
force-pushed
the
fix/param-decimal-datetime
branch
from
October 2, 2026 11:46
68279eb to
4b27091
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #58.
Decimal,date, anddatetimethroughconvert_python_to_java. Left to JPype, aDecimalreached the engine as aDouble(Decimal("12345678901234567890.123456789012345678")was stored as1.2345678901234567E+19, andWHERE amount = ?with the same value missed the rows holding it exactly), and adateordatetimewas refused with "No matching overloads".datetimeconverts to aLocalDateTimewith microseconds. Thejava.util.Dateit used to build kept milliseconds, soDATETIME_MICROSandDATETIME_NANOSstored...789000for...789123and a lookup by the same value found nothing. The engine storesDATETIMEas a UTC wall clock whatever the JVM's or the database's zone, so a naive value is now taken as that wall clock as it stands and reads back unchanged on every host (it used to be read as local time: 12:34 written on a UTC+9 host read back as 03:34); an aware value is converted to UTC and keeps its instant. On a non-UTC host, naive values written by earlier releases sit the zone offset away from the same wall clock written now; UTC hosts see no change. (Decided with the maintainer, 2026-10-02.)docs/api/type_conversion.mdgives the new mapping, the parameter behaviour, and the rule above; examples that store the current time usedatetime.now(timezone.utc).Engine side, for comparison: with the same values in Java a
BigDecimalparameter is stored exactly on 26.8.1, 26.9.1, and main. The engine's own precision bug for SQL numeric literals is filed upstream as ArcadeData#8872.Checked: the two new tests fail on the current dev wheel and pass on a wheel built from this branch; full suite 491 passed, 3 skipped; bandit (CI settings) clean.
🤖 Generated with Claude Code
https://claude.ai/code/session_01WWcDr7TwvcfMsQkeYQVHZr