Timestamp: convert epoch milliseconds in the proleptic Gregorian calendar - #1165
Open
lenamonj wants to merge 1 commit into
Open
Timestamp: convert epoch milliseconds in the proleptic Gregorian calendar#1165lenamonj wants to merge 1 commit into
lenamonj wants to merge 1 commit into
Conversation
…ndar Timestamp validated day-of-month with proleptic Gregorian leap rules but converted to and from epoch milliseconds through java.util.Date, which applies the Julian calendar before 1582-10-15. 1582-10-05T00:00:00Z and 1582-10-15T00:00:00Z shared one epoch millisecond, so compareTo called them equal while equals did not, and every earlier date denoted an instant days away from the one its text names (amazon-ion#165). Both directions now use exact proleptic Gregorian day arithmetic, with no Calendar allocated, which is the strategy amazon-ion#165 asked for after the Calendar-backed attempt was reverted for heap usage. calendarValue() moves the Julian cutover out of range so its fields agree. Two existing expectations encoded the Julian value and are corrected; a new test pins the cutover dates as distinct instants.
lenamonj
force-pushed
the
timestamp-proleptic-gregorian
branch
from
September 6, 2026 09:15
1c3b971 to
de78754
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.
Issue #, if available: #165
Description of changes:
Timestampvalidates day-of-month with proleptic Gregorian leap rules but converted to and from epoch milliseconds throughjava.util.Date, which applies the Julian calendar before 1582-10-15.1582-10-05T00:00:00Zand1582-10-15T00:00:00Zshared one epoch millisecond, socompareTocalled them equal whileequalsdid not, and every earlier date denoted an instant days away from its text.Both directions now use exact proleptic Gregorian day arithmetic with no
Calendarallocated, the strategy #165 asked for after the Calendar-backed attempt was reverted for heap usage.getMillis()changes only before 1582-10-15. Two test expectations that encoded the Julian value are corrected, and a new test pins the cutover dates as distinct instants; it fails on master../gradlew buildpasses.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.