To Time Stamp conversion behavour

[3DVision]

Hi,

I noticed that wierd behavour in number to time stamp function. If input was 0 then the time stamp indicator was:

00:00:00,000

DD.MM.YYYY

wich is OK, but IMHO the date should indicatecurrent either current date or default date. If I increase the input to 1 I get:

1:00:01,000

1.1.1904

So date defaulted to 1.1.1904 (NI why is that not the case when 0 is at input?) and why do I get 1h and 1s on the clock when only 1s should be added? There is more 😉 If I input 82801 (1 day and 1 second later) the timestamp shows:

00:00:01,000

2.1.1904

I discovered this while trying to implement Test start time and Elapsed time. What I did was get current time and substract the next current time stamp with previous one - jusl like when you time the VI execution with Tick count.

Another wierd thing is that when using a function to convert time stamp to seconds it appears that 1min is 40seconds then minut counter is increased and the seconds counter goes to -19 and counts up to 0.

A bug or am I missing something?

[RavensFan]

Zero is defined as a "null time".  So you wind up with a zero clock on an undefined day.

The timestamp is based on seconds since 1/1/1904 midnight Greenwich mean time.  So have 1 second, that is why you see the data as January 1, 1904.  I bet your timezone is set for GMT +1.  Your timestamp display is showing local time which is why you see 1 second after 1 AM on 1/1/1904.

When you add a days worth of seconds, you gen 1/2/1904, 1 AM.

There is no bug, just well-defined LabVIEW behavior.

If you are trying to subtract a current time from a start time, then you want to make sure your timestamp indicator is set to show Relative time.

---

@3DVision wrote:

Another weird thing is that when using a function to convert time stamp to seconds it appears that 1min is 40seconds then minute counter is increased and the seconds counter goes to -19 and counts up to 0.

---

I don't understand this sentency.  You would need to post a VI that demonstrates this.

[3DVision]

RavensFan,

according to this: http://www.ni.com/white-paper/7900/en the decimal representation {0,0} is the 01/01/1904 00:00:00.000 and not the "null time". Granted I totaly missed to account the timezone -> +1 for that.

But still, have you tried to run the for loop? 

Best regard

[RavensFan]

Interesting link.  I hadn't seen that one before.

But I think it is inaccurate.  I have only seen timestamps display zero as you have described, not as that link describes.  Perhaps "null time" was an incorrect phrase I used.   But it is the only terminology I could think of to describe the non-existent time of 00:00:00 MM/DD/YY.

You may also find this recent idea interesting.   Fix TimeStamp Control and Indicator to allow all reasonable values (means changing the "unwired" val...

I hope that an NI person who might read this thread would investigate that link you posted.  What it describes appears to be inaccurate based on the behavior of LabVIEW that I've always seen.

---

@3DVision wrote:

But still, have you tried to run the for loop? 

---

Are you talking about the While loop?

I can't run it because it is just a screenshot.  If you could attach a VI, then I can play with it. 

[tst · Accepted solution]

---

@3DVision wrote:

Another wierd thing is that when using a function to convert time stamp to seconds it appears that 1min is 40seconds then minut counter is increased and the seconds counter goes to -19 and counts up to 0.

A bug or am I missing something?

---

That doesn't covert a timestamp to seconds. It converts it to a cluster, which you then subtract from another cluster. The established behavior for that operation is to subtract each element in the cluster from the corresponding element in the other cluster and that's why you see -14 seconds. As you can see, LV refuses to translate that back to a timestamp.

If you want to get the elapsed time in seconds, just subtract the two timestamps from each other (you might have to convert to DBL before or after the subtraction).

[JÞB]

Yup no such thing as a "Relative Date Time Record" or "Relative Timestamp"  just clusters and numerics. 

[3DVision]

Well...I don't know what I was thinking to expect operations on clusters would work that way  

Everything works now, tnx

[rolfk]

---

@3DVision wrote:

RavensFan,

according to this: http://www.ni.com/white-paper/7900/en the decimal representation {0,0} is the 01/01/1904 00:00:00.000 and not the "null time". Granted I totaly missed to account the timezone -> +1 for that.

But still, have you tried to run the for loop? 

Best regard

---

That is correct! A timestamp of 0 is indeed 01/01/1904 00:00:00.000 GMT, the canonical start time of MacOS before it went X. However the timestamp control has been coded such that it considers this an invalid timestamp and displays the special format you observed to give an indication that this is most likely an uninitialized timestamp. Chances that someone really wants to display this exact time are VERY small.

Before there were timestamps (around < LabVIEW 6 or so) the double had to be used to display timestamps (set to display Absolute Time, which you still can do) and there the timestamp format did indeed show whatever local time corresponded to 01/01/1904 00:00:00.000 GMT, when given a 0 value. But somewhere around LabVIEW 7 NI decided that a 0 timestamp is the canonical invalid timestamp value as far as the timestamp display format is concerned. Since a timestamp is not anymore a floating point number they had to decide about how to represent an invalid timestamp, and while they could have reserved a special bit pattern of the 128 bit timestamp to be an invalid timestamp it seemed quite a smart move to use the default default data of 0 to indicate such.

[3DVision]

tst,

I pressed the accept as a solution too soon....Your idea of substracting two timestamps results in wrong elapsed time because of GMT zone (see image). I'm in GMT+1 time zone so that only works for GMT zone. I then tried to convert (typecast) the time stamp to DBL and substract it and it does not work either. 

The problem is in the definition (or interpretation) of time stamp. It is time zone independent! I see that as a big problem since we are all in different time zones. To ilustrate, lets say I'm in GMT+0 time zone and I use time stamp for say elapsed time in my software and I see no problem when I test the sw. If I sell my software in GMT+X time zone, the elapsed time would always be off by X. To ilustrate my point further consider image below. I call Get date/time to get time stamp and I do same thing 200ms later. Indicators of time1 and time2 are correct and if one would substract the time values the result is exactly 200ms. But If I use substract function (the operation is legit since this is the elapsed time in seconds form 1.1.1904) I get wrong value because of GMT+X.

Anyway, I solved the elapsed time problem using tick count as a point of origin like this:

Best regards

[rolfk]

The calculation is correct. The problem is that you convert the time difference back into a timestamp. A timestamp is considered always an absolute time and displays by default the local time. So your difference of 200ms is translated back into Jan 1, 1904, 0:0:0.200 GMT and then for display, it's corrected to local timezone. But just because you suppress or ignore the display of the date component doesn't make the timestamp magically a relative time. Absolute time is very much like a unit in many aspects. If you take a number that is kg and interpret it as seconds you get also rubbish.

The Number to Timestamp conversion has its uses, but can't be blindly applied to whatever values you have. It has to be a number that represents seconds since Jan 1, 1904, 0:0:0 or you get rubbish. A time difference or relative time is not seconds since this specific date and time, but seconds since whatever your reference system of your time difference calculation is, in your example this is the current time 2.

Just display the floating point value of the time difference directly and you will see a number of 0.2 which is correct. (well on your system you will apparently see 0,2 )