CachedDateFormat: Fix handling of ts with 654 as ms part
findMillisecondStart tries to find the position of the milliseconds in a
formatted timestamp by comparing the formatting to one where the
millisecond part of the timestamp was replaced with 654. If the
timestamp already has this millisecond part, it will switch to a
different value: 987.
However the check if it should switch to 987 was broken, as it was
comparing the magic number in microseconds to the millisecond part of the
timestamp in milliseconds, so this always results in false. This leads
to the comparison timestamp being identical and the function falsely
returning NO_MILLISECONDS.
The end result is that if the first timestamp we format since the
beginning of the current second has 654 as milliseconds, for all
following formatted timestamps the milliseconds will be identical when
within the same second, as the code never tries to find the millisecond
start again, but still happily uses the cache within one second without
updating milliseconds.
The fix itself is pretty easy: We just need to compare using the correct
units in findMillisecondStart. This commit also adds a testcase that
demonstrates the issue.
Fixes LOGCXX-506.
2 files changed
