Timestamp formatting fails when the nanoseconds component is zero

[rosstitmarsh]

I am hosting a PV with p4p that has a timestamp set in the past. If I view this PV with a "Text Update" widget and check the tool-tip it shows the correct timestamp. However if I view the timestamp using the new timestamp function it does not show the timestamp from the timeStamp field of the PV, it instead shows the timestamp of when the PV was first loaded by the display. I have seen the same behavior on the "PV Table" application but it is not consistently reproducible.

[rosstitmarsh]

I have figured out how to reproduce this. The timestamp formatter fails if the nanoseconds component of timeStamp is 0.

A PV with this value (timestamp of 2020-01-02T12:34:56) is displayed as the timestamp the PV was first loaded.

{'value': 0.0,
 'alarm': {'severity': 0, 'status': 0, 'message': ''},
 'timeStamp': {'secondsPastEpoch': 1577968496, 'nanoseconds': 0, 'userTag': 0}}

Whereas a PV with this value (timestamp of 2020-01-02T12:34:56.7) is displayed correctly.

{'value': 0.0,
 'alarm': {'severity': 0, 'status': 0, 'message': ''},
 'timeStamp': {'secondsPastEpoch': 1577968496,
  'nanoseconds': 700000047,
  'userTag': 0}}

[kasemir]

fails if the nanoseconds component of timeStamp is 0

That's a 1 in 1e9 chance of failure, or 0.0000001 %, so unlikely to be a problem 😏

Still, good find!

[rosstitmarsh]

Its a much higher percentage when reading from a system that has timestamps with only a second precision 😏

[rosstitmarsh]

I have identified the error to this comparison.

phoebus/core/pv-pva/src/main/java/org/phoebus/pv/pva/Decoders.java

Lines 175 to 176 in 77acc09

	final boolean valid = timestamp.getNano() != 0 &&
	(timestamp.getEpochSecond() > 0 && timestamp.getEpochSecond() != EPICS_EPOCH);

It does correctly parse the timestamps, but sets the invalid flag if the nanoseconds component is 0.

I have raised a PR to fix it.