Timestamp Formatting Truncates Instead of Rounds

[TomOrr0W]

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.

[Bob_Schor · Accepted solution]

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

[wiebe@CARYA]

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.

[Bob_Schor]

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

[wiebe@CARYA]

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.

[TomOrr0W]

The idea exchange entry has now been created:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Rounding-Version-of-u-Time-Format-Code/idi-p/3787702

[billko]

I wonder if this is why I often see the fractional part of the seconds handled independently of the rest of the timestamp?

[billko]

---

wiebe@CARYA wrote:

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.

---

I wish this is how progress bars worked.  I'm tired of seeing a full bar and 100% displayed and the task is obviously not complete, or the progress bar would go away.  It's especially annoying when it stays at 100% for half an hour or so.

[billko]

This convoluted way gets you the answer (with sound math, to boot):

edit:

LV 15 version.

[TomOrr0W]

The post from billko made me go back and look again at the code I ended up with to see if it would be a better fit.  While typing in timestamps, I noticed the below behavior.

It turns out the Timestamp doesn't actually Truncate.  There are a certain number of individual times where a timestamp less than a certain time rounds up to that time instead of down to the time 1 ms prior.  See the attached vi.