Repository navigation
Restore Timestamp parity with Dates - #7
Merged
Merged
Conversation
Port the current JuliaLang/julia#62994 resolution validation, equal-resolution promotion, raw-period conversions, Unix conversion, and subnanosecond formatting to the compatibility implementation. Keep fractional-scale arithmetic and calendar fields exact, and widen Int128 intermediates in conversions, rounding, and ranges. Construct local fractional-resolution clocks from whole seconds and raw ticks. Assisted-by: Codex (GPT-6.1 Sol)
The unchanged main branch fails safe trimming when its missing-rules error uses a three-string concatenation. Use concrete binary string calls to keep the same message while making the error path compilable on nightly Julia. This baseline fix is independent of Timestamp compatibility parity. Assisted-by: Codex (GPT-6.1 Sol)
Mirror JuliaLang/julia#62994's requirement for Integer or Rational nanoseconds per physical period unit. Floating metadata, including 1.0, previously rounded counts above 2^53 during Timestamp operations. Reject it consistently in construction, raw conversion, arithmetic, rounding, and physical range steps while preserving calendar range estimates. Assisted-by: Codex (GPT-6.1 Sol)
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.
Custom fractional-resolution timestamps currently truncate arithmetic and calendar fields, and wide Int128 counts can overflow during conversion and rounding. This restores the compatibility implementation's parity with JuliaLang/julia#62994: exact fractional scales, widened intermediates, raw-instant resolution validation, equal-resolution promotion, raw Hour/Minute conversions, Rational Unix conversion, subnanosecond formatting, and local fractional-resolution clocks.
Physical period unit metadata must be an
IntegerorRationalnumber of nanoseconds. Floating-point metadata, including1.0, previously rounded counts above 2^53; it now raises a clearArgumentErrorconsistently in construction, raw conversion, arithmetic, rounding, and physical range steps. Calendar range estimates keep their existing behavior.The Timestamp tests mirror the stdlib cases, with compatibility gates retained for behavior owned by older Dates. The custom-period documentation now describes the same extension contract. The follow-up adds 496 checks covering floating metadata, exact integer/rational alternatives, counts above 2^53, and Int128 boundaries.
A separate commit fixes an existing nightly trim failure in
zoned.jl:norules. Concrete binary string calls preserve the error message and remove the vararg dispatch that failed safe trimming on unchanged main. This commit is independent of Timestamp parity.Validation on macOS arm64:
revise-Datesrunner (8,083,538 assertions).Co-authored by Codex