04-17-2018 07:35 AM
While testing some code that displays timestamps, I noticed that Timestamp indicators (and the format into string options) truncate timestamps instead of round. This leads to minor rounding errors in floating-point math causing your result to be off by a much larger amount (in the attached vi, 1ms). The attached vi gives the same results in LabVIEW 2015 and LabVIEW 2017 - in case it affects the results, I tested this in Eastern Daylight Time using United States time format conventions.
Does anyone know if this truncation is intended behavior? If it is, I might add an idea exchange entry suggesting a rounding version of the %u time format code.
Solved! Go to Solution.
04-17-2018 08:01 AM
Timestamps are funny creatures, having their own ultra-precise representation (I seem to recall it occupies 16 bytes, or 128 bits). The suggestion that a rounding version of the fraction format, %u, be provided is not unreasonable, but you can do your own rounding by adding "one half and then truncating". In your example, where the number of seconds was 46.87299999..., which displayed (with a %u3 format at 46.872), adding 0.0005 to the number before displaying it using the (truncating) %u3 format will give the (rounded) 46.873 number you are seeking.
This problem may ultimately come down to the issue of how to display/format timestamps-as-floats. I'd be surprised if NI decided to make a change to TimeStamps after all these years ...
Bob Schor
04-17-2018 08:03 AM
Pretty sure it's intended behavior. It's how time is expected to work. It's not three o clock, if it's 14:59.999. A digital clock does not switch digits until the entire minute is past.
04-17-2018 08:16 AM
I agree. However, if the User wants "Time to the nearest round millisecond", there's a "rounding method" that they can use to get it. I have a colleague who likes to create File Names with Date and Time (to fractions of a second) as part of the name (I yell at him about this ...).
Bob Schor
04-17-2018 08:34 AM
I think a solution is not that obvious, it's kinda nasty stuff.
One problem that complicates the rounding is the limited resolution of the timestamp (any floating datatype really). For timestamps this is a problem.
For rounding to ms, round(T*1000)/1000 does not work. The value does not fit the type exactly, the value might be actually .872999999999999[...] , and still 872 is displayed, not 873.
Half a ms could be added to the original value, if the value is only used for visualizing. That would give the correct value in controls and indicators, but it would be bad for calculations.