TimeStamp arithmetic

[Mellroth]

Hi,

I don't know if this classifies as a bug or not, but I find it very annoying that simple arithmetics (lika add, subtract etc.) does not work with the Timestamp datatype. At least not returning a TimeStamp datatype in the result.

What do you say; is it a bug, a requested feature...or is it just me

/J

[AnalogKid2DigitalMan]

That would be looking into the future and cause a discontinuity in the time-space continuim.

It is odd. It may work if you convert timestamps to double, then add the doubles, convert addition to timestamp and then use a timestamp display.

[Herbert]

While I generally agree that we could potentially shoot for an even better user experience , there are some little helpers available in .\vi.lib\Waveform\TSOps.llb that can ease the pain of adding and subtracting time stamps.

Hope that helps,

Herbert

[eaolson]

QUOTE(JFM @ Feb 23 2007, 02:07 PM)

I don't know if this classifies as a bug or not, but I find it very annoying that simple arithmetics (lika add, subtract etc.) does not work with the Timestamp datatype. At least not returning a TimeStamp datatype in the result.

Timestamps are absolute times, not relative ones. So (23-Feb-2007) - (22-Feb-2007) = 24 hours makes sense, but (23-Feb-2007) + (22-Feb-2007) doesn't. After all, what should the result of "Wednesday plus Thursday" be, and would it be different from "Monday plus Tuesday"?

[Jim Kring]

QUOTE(JFM @ Feb 23 2007, 12:07 PM)

Hi,

I don't know if this classifies as a bug or not, but I find it very annoying that simple arithmetics (lika add, subtract etc.) does not work with the Timestamp datatype. At least not returning a TimeStamp datatype in the result.

http://lavag.org/old_files/monthly_02_2007/post-5958-1172260921.png' target="_blank">

What do you say; is it a bug, a requested feature...or is it just me

/J

This is not a bug, it's a feature. Here's what's up...

There are two types of "time" absolute time and relative time. The timestamp is an absolute time datatype and a floating point is (or should only be used for) relative time.

Subtracting two absolute times results in a relative time: 2/23/2007 - 2/21/2007 = 4147200.000 seconds (2 days).

Subtracting two relative times results in a relative time: 3.0 seconds - 0.8 seconds = 2.2 seconds

Adding two relative times is nonsensical: tomorrow + today = huh? (unless you're living in one of alpha's parallel universes)

Adding a relative time to an absolute time results in an absolute time: 2/23/2007 21:00:00 + 5.0 seconds = 2/23/2007 21:00:05

[David Boyd]

QUOTE(JFM @ Feb 23 2007, 03:07 PM)

Hi,

I don't know if this classifies as a bug or not, but I find it very annoying that simple arithmetics (lika add, subtract etc.) does not work with the Timestamp datatype. At least not returning a TimeStamp datatype in the result.

What do you say; is it a bug, a requested feature...or is it just me

/J

Nope, this is not a bug. It is IMO the only way timestamp math should work.

Remember that timestamps are a LV datatype which represents one thing only: an absolute point in time, timezone-independent, in the LV epoch (January 1, 1904). Valid operations on a timestamp include:

Adding a numeric (seconds offset). Result is a new timestamp.

Subtracting a numeric (seconds offset). Result is a new timestamp. Note that the subtract primitive only allows the offset to be wired to the subtrahend, not the minuend.

Subtracting another timestamp. Result is a numeric (seconds offset).

You cannot add two timestamps (adding two absolute points in time is meaningless).

You can increment or decrement a timestamp (the unit is, of course, one second).

You cannot multiply or divide with a timestamp.

You can round a timestamp. This rounds to the nearest whole second.

You can compare timestamps with other numeric types, or test for zero value.

Transcendental functions, exponentiation, and negation are right out. (Neither shalt thou count to two, excepting as thou proceedest to three...)

I'm not sure what 'pain' Herbert refers to. The primitives work just fine for me in all the use cases I just listed.

Hope this helps.

Dave

[Herbert]

I guess that reminds me of that we sometimes abuse the timestamp type for things it wasn't originally designed for.

I spare you the details

Herbert

[Mellroth]

Thanks for all your comments.

I'm not arguing that it should be possible to add two absolute times, what I'm trying to say is that I would like the TimeStamp data type be able to contain relative values as well. Then the addition/subtraction nodes would make sense.

Why should the TS be limited to absolute times, when this internally is in fact only a relative time (but displayed as absolute time)?

The choice of relative/absolute time could be made by the user (like for floating point values), when the value is displayed.

QUOTE(Jim Kring @ Feb 23 2007, 10:49 PM)

Adding two relative times is nonsensical: tomorrow + today = huh? (unless you're living in one of alpha's parallel universes)

I haven't been there yet, but I'm planning a visit really soon

Another point is that the TimeStamp (TS) data type is not a floating point value (as far as I understand it), but rather a more accurate representation. The TS can thus represent any point in time with the same accuracy. A floating point value can not do this, since a higher integer value (seconds), means less accuracy for the fractional part.

Anyway, from all the comments I conclude that this is not a bug.

I will now enter the 5th dimension, and see how the arithmetics work...

/J

[Aristos Queue]

QUOTE(JFM @ Feb 27 2007, 08:18 AM)

I'm not arguing that it should be possible to add two absolute times, what I'm trying to say is that I would like the TimeStamp data type be able to contain relative values as well.

QUOTE

The TS can thus represent any point in time with the same accuracy. A floating point value can not do this, since a higher integer value (seconds), means less accuracy for the fractional part.

Taking your two statements together... it would be logically impossible to have very high accuracy for a relative value. For relative offsets, all you need is a scalar value, for which floating point works just fine -- as it maintains very high precision.

[silver]

QUOTE(Jim Kring @ Feb 23 2007, 10:49 PM)

This is not a bug, it's a feature. Here's what's up...

There are two types of "time" absolute time and relative time. The timestamp is an absolute time datatype and a floating point is (or should only be used for) relative time.

Subtracting two absolute times results in a relative time: 2/23/2007 - 2/21/2007 = 4147200.000 seconds (2 days).

Whaaaaaaaaaaaat? 1 hour = 3600 sec. , 24 hours (1 day) = 86400 sec , 2 DAYS = 172800 seconds

my friend

Subtracting two relative times results in a relative time: 3.0 seconds - 0.8 seconds = 2.2 seconds

Adding two relative times is nonsensical: tomorrow + today = huh? (unless you're living in one of alpha's parallel universes)

Adding a relative time to an absolute time results in an absolute time: 2/23/2007 21:00:00 + 5.0 seconds = 2/23/2007 21:00:05

[Rolf Kalbermatter]

QUOTE(Jim Kring @ Feb 23 2007, 04:49 PM)

Adding two relative times is nonsensical: tomorrow + today = huh? (unless you're living in one of alpha's parallel universes)

I think you wanted to say absolute times here.

QUOTE(JFM @ Feb 27 2007, 09:18 AM)

Thanks for all your comments.

I'm not arguing that it should be possible to add two absolute times, what I'm trying to say is that I would like the TimeStamp data type be able to contain relative values as well. Then the addition/subtraction nodes would make sense.

Why should the TS be limited to absolute times, when this internally is in fact only a relative time (but displayed as absolute time)?

Trying to force your way here? Since you want the addition to work on timestamps they should be made to support relative times?

But the timestamp was just invented to be able to properly distinguish between absolute and relative times. Before the timestamp datatype was available it was simply a floating point (well very early in LabVIEW it was in fact an unsigned 32bit integer but that got slowly remedied in later LabVIEW versions) number too. This gave problems as it was not really clear if a value was supposed to be absolute times or not

So the timestamp was added just for that reason. To have a unique datatype that could represent absolute time so that LabVIEW could make smart decisions how to operate on that. The disallowence of the addition operator on timestamps is one of those smart decisions.

QUOTE

Another point is that the TimeStamp (TS) data type is not a floating point value (as far as I understand it), but rather a more accurate representation.

It is in fact a fixed point representation. 64 bits for the integer part and 64 bits for the fractional part. As such it is obviously at least as accurate as a double floating point number for integer numbers but in fact can't represent the same range as a flaoting point number. While a flaoting point number can represent numbers from ~ -10^308 to 10^308 seconds the timestamp only can go from ~ -10^19 to 10^19 seconds (+-3*10^11 years relative to 1904). The difference is however that the integer part of the timestamp has still a resolution of 1 seocond when representing such a number while the floating point will have a resolution of ~10^293 seconds when representing its maximum value. In fact a 64 bit floating point number will get a resolution higher than 1 second as soon as it goes over ~ +-4.5*10^15 seconds (only ~1.4*10^8 years).

The additional 64 bytes of a timestamp for the fractional part allow for a total resolution of 2^-64 seconds which amounts to ~ 5*10^-20 seconds. Not sure if quantum theory allows for such a small time interval at all but I think LabVIEw 8 only used 32 bits of those 64 fractional bits anyhow.

Still all this number theory is really not that interesting and if it would be only because of the range and resolution a double floating point could have worked for a few more thousend years for sure as long as you don't require sub millisecond resolution. But the additional benefit of a distinct datatype really made the timestamp extra interesting. The only complain I have is that they didn't think about extra features such as allowing for timezone information being encoded in the timestamp too. I guess reserving 16 bit of the 64 fractional bits for this wouldn't have made the timestamp less useful. After all a resolution of 3.5*10-15 for a timestamp (around 3 femto seconds) still seems quite above any possible need even for hyper physics.

Rolf Kalbermatter