LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to overcome timestamp conversion rounding?

Solved!
Go to solution

Greetings,

 

I'm having a bit of trouble implementing some time "math" in a current project.  This is the first time I've done this, so I hit an unexpected snag.  

 

timestamp rounding.jpg

 

I have two time "controls".  Each are configured to display only time and no seconds.  

 

On my first run of the VI, one control minus the other was zero if the two time values were the same.  But after adjusting one time control the first time, a rounding error was introduced.  Now if I subtract what appear to be two identical values, I get a difference of one second.  

 

What I'm not sure of, is the best way to overcome this problem.   

 

 

---------------------
Patrick Allen: FunctionalityUnlimited.ca
0 Kudos
Message 1 of 8
(3,915 Views)
Solution
Accepted by topic author pallen

This indicates that the seconds aren't the same. You probably used the up/down controls. This changes the seconds even though you're not displaying them. You could set the data range to have an increment of 60 so that the increment/decrement move by 60 seconds, but for some reason this prevents the decrement button from working. Not sure if this is a bug or not. Need to investigate...

 

P.S. You do not need to convert to DBL to subtract two timestamps. Just wire them directly to the Subtract function. 

Message 2 of 8
(3,906 Views)

Sneaky little buttons! 

 

 

I was just about to say that I've already figured out a way to let my MySQL database do the math from me  (eg. SELECT TIMEDIFF (tmeEnd,tmeStart) from Time WHERE idxTime='12840';)

 

I still may do it that way, just because it looks like it might be more convenient.  But it's very good to know that the seconds are still there and can be altered by the inc/dec buttons.  

 

Thanks.   

 

 

---------------------
Patrick Allen: FunctionalityUnlimited.ca
0 Kudos
Message 3 of 8
(3,893 Views)

smercurio_fc wrote:

 You could set the data range to have an increment of 60 so that the increment/decrement move by 60 seconds, but for some reason this prevents the decrement button from working. Not sure if this is a bug or not. Need to investigate...

 


That would sound like a bug.  I tried to duplicate in LV 8.6, but both the increment and decrement worked properly moving it a minute at a time.

Message 4 of 8
(3,888 Views)
Thanks for checking that, Ravens Fan. I was going to look at it later today or over the weekend. I would agree that it looks like a bug in 8.2.
0 Kudos
Message 5 of 8
(3,882 Views)

I saw an odd behavior on 8.2.1.  When the control is intialized to its default value at the base time of zero  (for me 12/31/1903 7pm), I could increment and decrement by a minute, but I could not go below 7pm.  If I went in and typed in a new time, then the increment/decrement could go up and down from 7pm just fine.  If I did a Reinitialize to Default on the control, it went back to the behavior of not going below 7pm.

 

In LV 8.5.1, I could see this as well, but I also saw some different weird behavior.  If I do a decrement, it would count down by a minute, but when I got to a certain value it started counting down by 10 seconds,  then by 1 second, then by .1, then by .01, then by .001 seconds.  However, I find it is kind of hard to recreate this.

 

Also, at times even in 8.6, the control would show an empty time of 00:00:00 MM/DD/YY. Go up a minute it would be 7:01pm.  Down a minute, back to empty, down another minute it would be 6:59 pm.  Back up and it would be empty time.  Do something different such as type in a number, and the time of 7pm would show up.

 

Another thing seen in the attachment from LV8.6 (but appears in other versions as well).  Why does the dialog box show the date as

 

7:00:00.000 PM
12/31/0/

for the min field

 

but 7:00:00.000 PM
12/31/00 in the max field.

 

What does a year of 0/ actually mean?

 

 

There seem to be a lot of oddities with a time control and many of them seem to be associated with either time zero or a "null" time.  And the odd behavior changes depending on other things you might do around it like typing in a time.

 

 

Just some ideas for you to play around with.

Message Edited by Ravens Fan on 07-17-2009 01:43 PM
0 Kudos
Message 6 of 8
(3,868 Views)

Thanks for that Ravens Fan.   I just checked on my box with 8.6 installed, and it works just fine.  But the "bug" is still present in 8.5 which is what I'm using on this project. 

 

---------------------
Patrick Allen: FunctionalityUnlimited.ca
0 Kudos
Message 7 of 8
(3,865 Views)

The timestamp itself has a range of about ±300×109 years. Unfortunately, the timestamp indicator was created when the timestamp was a U32, so has a much smaller display range. What you are seeing is the timestamp display attempting to display something it cannot. If the timestamp is outside the approximate region Jan 1, 1904 to about 2040, it will not display correctly. If you need a workaround to this issue, let us know.

Message 8 of 8
(3,837 Views)