Details
-
Bug
-
Status: Resolved
-
Low
-
Resolution: Fixed
-
None
-
Low
Description
These tests create timestamps from Unix time, but this is done as int math with the result stored in a long. This means that if the test is run at certain times, like 1505177731, corresponding to Tuesday, September 12, 2017, 12:55:31, the test can have two timestamps separated by a single second that reverse their ordering when multiplied by 1000000, such as 1505177731 -> 2147149504 and 1505177732 -> -2146817792. This causes a variety of test failures, since it changes the reconciliation order of these cells.
Note that I've tagged this as trivial because the problem is in the manual construction of timestamps in the test; I know of nowhere that we make this mistake with real data.
Attachments
Issue Links
- relates to
-
CASSANDRA-10266 Introduce direct unit test coverage for Rows
- Resolved