Calculate the time difference between two time stamps?

[duglia]

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

[Himanshu_Goyal]

Hello Duglia,

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

[PhillipBrooks]

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

[Barionics]

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?

[Sam_Sharp]

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: https://www.ni.com/en/support/documentation/supplemental/08/labview-timestamp-overview.html

[alanturing]

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

[Hooovahh]

---

@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.

[CoastalMaineBird]

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.

[CoastalMaineBird]

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?

[tst]

---

@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.