[
https://issues.apache.org/jira/browse/CASSANDRA-21621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-21621:
-------------------------------------------
Test and Documentation Plan:
SimpleDateSerializerTest (12 tests) and DefaultMaskingFunctionTest (5 tests)
pass on JDK 17.
SimpleDateSerializerTest gains testOutOfBoundsHighMillis and
testOutOfBoundsLowMillis, one millisecond outside each bound, and
testSupportedBoundsMillis, which holds the day count of each bound itself.
Status: Patch Available (was: Open)
> A date built from a timestamp is not range checked
> --------------------------------------------------
>
> Key: CASSANDRA-21621
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21621
> Project: Apache Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
> Reporter: Michael Semb Wever
> Priority: Normal
> Fix For: 5.0.x, 6.0.x, 7.x
>
>
> {{SimpleDateSerializer.dateStringToDays}} rejects a date string outside the
> range the {{date}} type can hold, but
> {{SimpleDateSerializer.timeInMillisToDay}} applies no range test:
> {code:java}
> public static int timeInMillisToDay(long millis)
> {
> return (int) (Duration.ofMillis(millis).toDays() - Integer.MIN_VALUE);
> }
> {code}
> A day count is a signed 32-bit value shifted by {{Integer.MIN_VALUE}}, so a
> timestamp further from the epoch than 2^31 days wraps and yields a date that
> bears no relation to the input. {{timeInMillisToDay(Long.MAX_VALUE)}} returns
> a day count near the year 1970.
> {{SimpleDateType.fromTimeInMillis}} reaches that method, and {{TimeFcts}}
> exposes it through {{toDate(timestamp)}} and through the date arithmetic of
> {{TemporalType.addDuration}} and {{TemporalType.substractFrom}}. A query can
> therefore build a wrong date with no error. The severity is Low because a
> timestamp that far from the epoch is rare, and the whole {{timestamp}} range
> beyond 2^31 days lies more than five million years from now.
> The patch moves both range tests into {{timeInMillisToDay}}, and lets
> {{dateStringToDays}} reach them through a private overload that keeps the
> source string in the message, so the message a date string produces does not
> change.
> {{MaskingFunctionTester}} used {{timeInMillisToDay(Long.MAX_VALUE)}} as its
> maximum {{date}} value, which is the wrap itself, so it now names the maximum
> date the type supports.
> Patch:
> [mck/upstream/date-millis-range/5.0|https://github.com/thelastpickle/cassandra/tree/mck/upstream/date-millis-range/5.0]
> Provenance:
> [1032ba3047|https://github.com/datastax/cassandra/commit/1032ba30474d16f4b7309be48c0ab69c3ec34e56]
> by Jakub Zytka and Ulises Cervino Beresi. That commit carries the same range
> test; this patch keeps the existing message format and adapts the one
> upstream test that relied on the wrap.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
