[python] Read row-format TIMESTAMP values in the precision's time unit - #10125
Open
jackylee-ch wants to merge 1 commit into
Open
jackylee-ch wants to merge 1 commit into
jackylee-ch wants to merge 1 commit into
Conversation
Contributor
|
Reviewed the row-format timestamp wire decoding against the Arrow precision mapping and Java timestamp conversion. The seconds, milliseconds, microseconds, and nanoseconds formulas are consistent, including pre-epoch floor semantics and genuine sub-microsecond |
The row-format reader returned a TIMESTAMP value in milliseconds for precision <= 3 and microseconds for precision > 3, but PyarrowFieldParser.from_paimon_type maps the precision to four Arrow units (0 -> s, 1-3 -> ms, 4-6 -> us, 7-9 -> ns) and the value is placed into that type without conversion. Only precisions 1-6 agreed: a precision-0 value was read as seconds from a millisecond integer (x1000, overflowing to year 52626), and a precision 7-9 value was read as nanoseconds from a microsecond integer (/1000). Return the value in the Arrow unit the precision maps to: seconds for 0, millis for 1-3, micros for 4-6, nanos for 7-9. The wire format (a millis long plus, only for precision > 3, a nano_of_milli varint) is unchanged and already written that way, so this is a read-side fix.
jackylee-ch
force-pushed
the
py-row-timestamp-unit
branch
from
September 23, 2026 04:53
3381eb5 to
f5875b5
Compare
Contributor
|
Conflicts. |
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
3 participants
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.
Purpose
The
rowfile-format reader returned aTIMESTAMPvalue in milliseconds for precision ≤ 3 and microseconds for precision > 3. ButPyarrowFieldParser.from_paimon_typemaps the precision to four Arrow units —0 → s,1-3 → ms,4-6 → us,7-9 → ns— and_build_tableputs the integer into that type without conversion. So only precisions 1-6 agreed:TIMESTAMP(0)(Arrows): a millisecond integer read as seconds — ×1000, overflowing (a 2020 instant renders as year 52626).TIMESTAMP(7-9)(Arrowns): a microsecond integer read as nanoseconds — ÷1000 (a 2020 instant renders as 1970).The reader now returns the value in the unit the precision maps to (seconds / millis / micros / nanos). The wire format (a
millislong plus, for precision > 3, anano_of_millivarint) is unchanged, so this is a read-side fix.Tests
test_timestamp_precisionsround-tripsTIMESTAMP(0/3/6/9)and asserts exact values (fails on master:TIMESTAMP(0)overflows,TIMESTAMP(9)reads 1970).test_timestamp_nanos_decoded_from_wirepins the nanosecond formula against a hand-built wire buffer (nano_of_milli=123456), the genuine Java-written case.