timestamp rounding problem

[Hooovahh]

---

PhillipBrooks wrote:

You can set the units for the constant to hours and add that directly to the timestamp; no units scaling required... 

---

I use this feature all the time.  It is one of those features that I like to show because many developers don't know you can do this.  You can also do the same for the numeric control setting up custom displays allowing the user to enter relative time in a double control in an intuitive way.

[rcpacini]

On a related topic, here's my workaround to round fractional seconds to the nearest microsecond using the Date/Time to Seconds. You lose some digits of precision but it fixes the timestamp rounding issue.

 

[DavidBoyd]

rcpacini,

At the risk of extending a two-year-old thread, I'm going to add a snippet that may prevent some undesireable rounding issues.  Note that I left the front panel timestamp control and indicator set for UTC display with a ridiculous number of decimal places.  Change the "frac prec" integer to 6 for microseconds, 3 for milliseconds... you get the idea.

Dave

[crossrulz]

And at the risk of extending the thread even more, here is another alternative (kind of a merger of the last two posts)

[DavidBoyd]

Well OK, one more bump to the old thread (can't resist!)

While I wouldn't want to question the wisdom of a Knight, I will say that my solution was intentionally avoiding the "timestamp to date-time record" and "date-time record to timestamp" round trip.  I'm not engaged enough to want to code up a time trial, but I would expect those operations take both more CPU cycles and more memory.

Having said that, I still think this is all a bit of a solution in search of a problem.  What is the use case for rounding off the precision of a timestamp wire?  In general I expect it's really just about rendering the value for display purposes.  And if it's about comparing two TS'es for an arbitrary measure of equality, subtract them and test the difference, in seconds, to a limit.

Dave

[crossrulz]

---

@DavidBoyd wrote:

While I wouldn't want to question the wisdom of a Knight

---

Feel free.  I am far from perfect.

My gut feel is that the conversion to/from the time rec is slower than yours (have not done any benchmarks myself).  But it is simple.  If efficiency is not a huge problem, easiness to read comes out ahead in my book.

---

@DavidBoyd wrote:

Having said that, I still think this is all a bit of a solution in search of a problem.

---

I fully agree.  I only joined in just for the fun of trying to simplify the previous solution.

[Hooovahh]

Drum roll please....<pauses for drum roll>

DavidBoyd is the winner (until Altenbach submits his I assume)

My speed test shows that with 1,000,000 time stamp conversions it takes David's solution 0.117 seconds, and Tim's 1.3 seconds.  A pretty significant difference.  Readability can be a concern but as long as this is wrapped in an inlined subVI, and a block diagram comment, or VI description explains what it is doing, I see no reason to have a 10x slow down.