LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Calculate the time difference between two time stamps?

hello how can I calculate the time difference in ms between two time stamps?

0 Kudos
Message 1 of 25
(17,999 Views)

Hello Duglia,

 

Time.jpg

 

Check this. This will give you the difference between two time stamp.

Thanks and Regards
Himanshu Goyal | LabVIEW Engineer- Power System Automation
Values that steer us ahead: Passion | Innovation | Ambition | Diligence | Teamwork
It Only gets BETTER!!!
Message 2 of 25
(17,993 Views)

Note that the units in the example above will be seconds. Multiply by 1000 for msec.

 


Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.

"You are what you don't automate"
Inplaceness is synonymous with insidiousness

0 Kudos
Message 3 of 25
(17,983 Views)

I note that the subtract does a coercion on the timestamp, which is 128 bits in length. Might there be instances where this causes the subtraction to fall down? I guess that, if you convert to extended precision float (also 128 bits) it will be OK?

0 Kudos
Message 4 of 25
(16,186 Views)

The LabVIEW timestamp format is designed to work with a really high range of accuracy - on Windows with millisecond timing resolution you're probably fine with a normal floating point number.

 

Source: http://www.ni.com/tutorial/7900/en/


LabVIEW Champion, CLA, CLED, CTD
(blog)
Message 5 of 25
(16,166 Views)

I agree with Barionics. Timestamps are just 128 bit integer numbers. The fact that when subtracting them you do not get a timestamp is totally disturbing. If one cares to bring around timestamp values it is precisely because he/she is worried about the lest significant bits. How could I measure difference intervals of the order of nanoseconds when most of the most significant bits are used to encode the date?

 

Please extend the difference operator to the timestap type (128-bit integer). It is something missing that will extend the type use case.

 

Cheers

0 Kudos
Message 6 of 25
(15,980 Views)

@alanturing wrote:

The fact that when subtracting them you do not get a timestamp is totally disturbing.


I suspect NI did this because this is the most common desired output.  If I subtract 2015 from 2014 I'd get...1904.  That doesn't seem too useful and would probably confuse new users.  NI choose to output the data as a double representing the seconds between the two dates which works well.  Having the option to output the 128bit timestamp seems like it could be a good idea.  You should post it on the idea exchange.

Message 7 of 25
(15,917 Views)

I'm not sure you need to, but you can take it apart and do the math yourself if you like.

 

See this format guide.

 

It's basically an I64 and a U64.  the I64 is the number of whole seconds after (or before) T0.

The U64 is the FRACTION of a second after the whole second.  So you have a resolution of  2^-64 seconds.

 

I would imagine that the COERCE and SUBTRACT operations fit as much of the fraction into the result as they can, depending on the difference in the whole numbers.

 

i.e. Subtracting 2015.0904.1854.30.905 - 2015.0904.1854.20.405 gives you about 10.5 seconds - there's plenty of room to pack femtoseconds into that DBL.

 

but subtracting 2015.0904.1854.30.905 - 1921.0102.0700.31.111 is over 90 years - you don't have enough space to handle femto second resolution.

 

But work it out for yourself: 90 years x 365 days * 24 hours * 60 mins * 60 seconds - whatever that number is, does it need more than 40 bits to represent? (is it less than 2^40)?

 

If not, then you still have 16 bits left over to use for sub-second resolution, which will cover mSec easy.

 

But you can take it apart if you like.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 8 of 25
(15,890 Views)

The fact that when subtracting them you do not get a timestamp is totally disturbing

 

 

Not to me.  To make that work you would have to have TWO kinds of time stamps: Absolute, and Relative.

Subtracting an Absoliute from an Absolute would give you a Relative.

 

I see all kinds of nastiness coming from that.

 

Either that, or you have to have a true T0, and define the year zero as that time, such that 2015 - 2014 is year 1.

 

But how many femtoseconds has it been since year 0 ?  How big would the integer have to be to accomodate that?

 

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

Message 9 of 25
(15,886 Views)

@alanturing wrote:

The fact that when subtracting them you do not get a timestamp is totally disturbing.


Not only is this not disturbing to me, but it's the only thing that makes sense. Timestamps are by definition a data type encoding absolute time (not as integer, as you say, but as a fixed point fractional value, which can also be looked at as two integers). When you calculate the difference between two absolute times, you get relative time, which is by definition not a timestamp (and some of the absurdities of this have been pointed out).

 

As for calculating a difference in ns, I haven't personally had the need, and I expect that the majority of users don't either. I haven't done the calculation or testing, but I would expect the DBL data type to easily hold ns values as long as your seconds aren't too large. If it's not doing that, either my intuition is wrong (entirely possible) or NI hasn't been careful enough in how they implemented the subtraction code.

 

In any case, it should be easy enough for you to write a very simple VI which will take the timestamp, type cast it into a fixed point value or a cluster of two integers, do the subtraction on those and output the result in any format you wish, something I expect your namesake would have done in his sleep.


___________________
Try to take over the world!
Message 10 of 25
(15,844 Views)