From 12:00 AM CDT Sunday, October 17 - 11:30 AM CDT Sunday, October 17, ni.com will be undergoing system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Timestamp Formatting Truncates Instead of Rounds

Solved!
Go to solution

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.

0 Kudos
Message 1 of 17
(1,809 Views)
Solution
Accepted by topic author TomOrr0W

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

0 Kudos
Message 2 of 17
(1,788 Views)

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.

 

 

0 Kudos
Message 3 of 17
(1,787 Views)

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

0 Kudos
Message 4 of 17
(1,780 Views)

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.

Round time.PNG

0 Kudos
Message 5 of 17
(1,774 Views)
0 Kudos
Message 6 of 17
(1,683 Views)

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

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 7 of 17
(1,670 Views)

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.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 8 of 17
(1,668 Views)

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

 

edit:

LV 15 version.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 9 of 17
(1,657 Views)

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.

0 Kudos
Message 10 of 17
(1,642 Views)