time stamp difference wrong. why??

[OPCer]

Dear all,

i get some very unintuitive behaviour when substracting time stamps from each other. Can you tell me why "hour" shows "1" where obviously "0" would be correct?

[RavensFan]

Let me guess.  Your time zone is GMT +1:00

I run your VI and I see 12/31/1903 and 19 hours because I am GMT -5.

You ar creating a relative time by subtracting two timestamps, but then feeding that into a function (Seconds to Date/Time) that is expecting an absolute time and uses your timezone as part of that calculation since 0 seconds is the equivalent of midnight the morning of Jan 1, 1904 at GMT.

What are you actually trying to do?

[Ranjeet_Singh]

Use format date/time string to retrieve the DD MM YYYYY HH MM or SS and then subtact. In this way you will receive the perfect data irrespective of your zone

[OPCer]

Thank you for your suggestions!

@ RavensFan

I was actually looking for the most simple and intuitive way to substract the current loop time from the start time to get the elapsed time and display all three.

I did not expect to run into GMT issues. To me, this feels odd. Am i seriously intended to change code every 6 months, when out GMT status changes???

@Ranjeet_Singh

so i would have to re-convert the string into numbers, is that what you mean?

I guess my approach is not really good. in matlab, tic toc does it. what should i use here?

[RavensFan · Accepted solution]

Subtract the two time stamps like you are now.  Feed that into a numeric indicator.  Set the display format for that numeric indicator to be relative time.  There is a choice there for hours days and minutes that looks like %<%H:%M:%S>t in the advanced editing format.  If you want to show days, then make it %<%D:%H:%M:%S>t   There is no need to mess with strings.

[Bob_Schor]

There are multiple things "wrong" with your example (which can easily be reworked to give the "correct" answer.  Here is what you should have coded, with explanations for the differences:

• Remember Data Flow.  If you have the Wait (ms) and inner Get Date/Time in Seconds functions hanging "free in the breeze" inside the While loop, you have no idea when they will execute.  In my test, they both executed within microseconds of the initial Get Date/Time function outside the loop, so that the elapsed time was (correctly) 0.  Fix this by putting them in a Sequence Structure (this is almost the only time I use Sequence structures).  Now the sequence is Get Time (outer), wait 100 msec, Get Time (inner), so the expect Elapsed should be 0.1 seconds.
• Your Start and Current will now be correct.  Note when you subtract, you get out a Dbl.  If you look at how TimeStamps are implemented, they are "seconds since the beginning of 1 Jan 1904, GMT (or UTC 0).  If you simply display this "number of seconds", as I do in Delta-t, you will get 0.1, the correct answer.  If, however, you attempt to convert this time, 0.1, back to a TimeStamp, it will convert to "Number of seconds from 1 Jan 1904, GMT", which should be a date and time very close to 1 Jan 1904, with the date and time dependent on your local Time Zone.
• I wired a True to the Stop indicator to get the While Loop (why is this in a While loop?) to stop so I could "see" the indicators.  This isn't really a "bug", I suppose, but I wouldn't wouldn't wire a False here ...

Bob Schor

[Norbert_B]

The point is that you have a misconception here regards the way LV displays timestamps.

The timestamp display is by default configured to display timestamps in "System Time Format" (both time of day and date). If you do this, the timestamp is automatically "corrected" by regional computer settings.

So the difference you have after the subtract primitve is what you expect. Turning it to a timestamp has a "correct" timestamp as the difference is offsetted (new word?) with the date 1/1/1904 00:00:00.000.

The modification comes by the timestamp display as you have it "System Time Format". You can modify the setting to be "Custom Time Format" to prevent the timezone correction.

Norbert

[OPCer]

@ RavensFan

thank you, i regard this as fairly quick & straight forward solution.  But is ther even a better one? It appears to me still as very bulky, compared to how fundamental this "function" is.

@ Bob_Schor

thank you for your answer, i really appreciate to read comments on good programming practices. I am clear on why you use the flat sequence here. In my final apllication this is not an important aspect, but now i am aware of. (I want to see the elapsed time after hours, where loop duration is about 100ms)

I was also aware that the stamp conversions happen, so i thought to omnit the date and only take the time part of it. that the gmt correction would kick i i did not expect.

Once you let the while loop run only a single time, i dont know why you need it any more. except you would do some shift register trick and the VI itself being part of a higher-instance-loop

@Norbert_B

thanks for pointing this out!

[OPCer]

thank you for your answers, i think the quickest and easiest way is the one RavensFan proposed.

@ Bob_Schor:

thanks for your advice, i appreceate them. I am cler about the sequential structure in this case.

I know of techniquies using once-through while loops for their shift register. otherwise, i dont know why you would keep it.

[Alhaidar]

I think there is a Bug in "to time stamp" function 

i have tried to configure the indigator as you said but still there is difference one hour !!

LV help said "it is time zone independent" but it's not really so.

logically all these functions should be time zone independent.