Support larger dates in TypeDate marshalling #1692
Merged
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.
We are using nanosecond precision when reading a
TypeDate
into atime.Time
value, this limits the dates we can accurately read and write from cassandra to[1677-09-22, 2262-04-11]
since outside of this range we end up with integer overflow. Dates outside of this range encode correctly and are persisted in Cassandra, but are then read as an incorrect value.The new supported date range is
[-5877641-06-23, 5881580-07-11]
given that we are decoding the epoch day as a 32 bit int (-2147483648
= minimum int =-5877641-06-23
). I think it's possible to expand the range if ever needed by decoding a 64 bit int and usingtime.Unix(seconds, 0)
, but I didn't think it was worth looking into that change.Please let me know if I missed anything from the testing.