fix(isthmus)!: convert precision_time and precision_timestamp up to nanoseconds - #1318
Open
alexandrefimov wants to merge 2 commits into
Open
alexandrefimov wants to merge 2 commits into
alexandrefimov wants to merge 2 commits into
Conversation
…anoseconds SubstraitTypeSystem capped TIME, TIMESTAMP and TIMESTAMP_WITH_LOCAL_TIME_ZONE at microseconds, so a plan carrying a nanosecond precision_timestamp was refused although Calcite 1.42 builds such a type the moment the ceiling allows it, and TimestampString carries the digits. Raise the ceiling to nanoseconds. Precisions 10 to 12, which Substrait allows and Calcite clamps rather than reports, stay refused, naming the bound. Converting back, a value is a 64-bit count of its own unit, so nanoseconds reach only 2262 where a TimestampString reaches 9999: a timestamp outside that range is now reported instead of wrapping. Closes substrait-io#995
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 10 included reviews per hour; 8 remain after this review. 📝 WalkthroughWalkthroughIsthmus now supports precision 9 for ChangesPrecision conversion
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to The change enables nanosecond precision and reports timestamps outside the representable range. No actionable merge-blocking issue is established by the supplied evidence. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
The floored seconds of 1677-09-21 00:12:43 overflow when scaled to nanoseconds although the value fits once the sub-second part is added back, so a negative timestamp borrows that second before scaling. Pin both ends of the range and the nanosecond past each.
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.
SubstraitTypeSystemcappedTIME,TIMESTAMPandTIMESTAMP_WITH_LOCAL_TIME_ZONEat microseconds, so a nanosecondprecision_timestampwas refused although Calcite 1.42.0 builds such a type the moment the ceiling allows it. Raise it to nanoseconds; 10 to 12, which Calcite clamps rather than reports, stay refused and name the bound.Converting back, a Substrait temporal value is a 64-bit count of its own unit, so nanoseconds reach only 2262 where a
TimestampStringreaches 9999. A timestamp past that is now reported instead of wrapping into a different instant.Closes #995
BREAKING CHANGE: precision_time, precision_timestamp and precision_timestamp_tz convert up to nanoseconds, so plans that were refused now convert and TIME(9) or TIMESTAMP(9) can appear where the type system allowed at most 6.
Summary by CodeRabbit
TIME,TIMESTAMP, and timestamp-with-local-time-zone values now support precision up to nanoseconds. Time-with-local-time-zone values retain their existing precision limit.