tree 1cb87f90edc782e89e8b72cd8e80093b44baf71b
parent 24125060f6d2e1b68187bec8eb1ff064a85520db
author Klemens Schölhorn <klemens.schoelhorn@advantest.com> 1566392774 +0200
committer Thorsten Schöning <tschoening@am-soft.de> 1566581261 +0200

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.