Why this discrepancy in time functions?

[CoastalMaineBird]

LabVIEW 8.6.1f2, Win Vista

When you run a test in my app, there are header windows with stuff to fill out, and then the test monitor window comes up.

When you click START (A), I start recording, and the test runs for a certain time (about 20 minutes unless aborted), then recording stops (B).

I'm still sampling; you may or may not do some instrument calibration (an indeterminate period of time), and then you click DONE, and a test file is written(C).

I use GET DATE/TIME IN SECONDS to record the time at A and B, and FORMAT DATE/TIME STRING to record the time at C. All inputs to bothe these functions are unwired (default).

I need the times as timestamps, for arithmetic purposes, at A and B, while C is just a string for display purposes. 

On my machine, all is as expected.  However, when I examine data files produced by my client, I see weird things.

For example, one file has A at 11:44:17 and B at 12:04:25, but C is 11:19:25, about 45 minutes BEFORE the end of the test.

Another file has A at 3:18:18 and B at 3:38:34, but C at 2:49:39, about 50 minutes BEFORE. (about 10 minutes of cal work done here).

Another file has A at 10:39:20 and B at 10:59:31, but C at 10:00:10, about an HOUR before the end. (There were no calibrations done here).

What's going on here?  Why the discrepancy?

Is it possibly a DST setting on his computer that's not set right?

Why does one function respect this setting and another function not? 

[CoastalMaineBird]

More info: there may (or may not) be some intermediate events recorded during the test, when there are, they are recorded using the FORMAT DATE/TIME STRING function and appear an hour earlier than the start of the test.

But only on my client's machine, not on mine. 

[rex1030]

At C, wire a new "get date/time in seconds.vi" to the format date/time string input.

And yes, your client is not adjusting for daylight savings time on his computer. 

Message Edited by rex1030 on 10-28-2009 04:22 PM

[CoastalMaineBird]

Why would one function respect the DST setting, and the other not respect it?

Message Edited by CoastalMaineBird on 10-28-2009 03:30 PM

[rex1030]

What baffled me about your problem, is that if it was solely the problem of daylight savings time or UTC differences it would be a matter of hours, not minutes. Also, if you could post some pictures (png) of your code that would really help. It almost sounds like you aren't reading the time in part c when you think you are, which is why i suggested adding the get date/time in seconds right when you want to write the file.

Did you try to wire the get date/time in seconds to the format date/time like I suggested?

Also enabling the UTC checkbox will convert to UTC time which is independent of DST problems. However using UTC can be annoying for anyone relating that time to where they are in their head (UTC -5 etc).

[CoastalMaineBird]

I just tested my computer. 

I made a VI with both functions tied to indicators.

Both times agreed.

I unchecked the AUTOMATICALLY CORRECT FOR DST in the control panel.

The system clock went from 4:30 to 3:30.

The LabVIEW program did not change (both said 4:30)

I quit LabVIEW and started again, this time they both said 3:30.

I checked the AUTOMATICALLY CORRECT FOR DST in the control panel.

It behaved the same way, in the other direction.  IOW, they always agreed. 

My client is on XP, I'm on Vista, wonder if that's relevant... 

[CoastalMaineBird]

 if it was solely the problem of daylight savings time or UTC differences it would be a matter of hours, not minutes.

Well, that I can explain by the cal stuff done at the end.  If there is no CAL operation, then the time is almost exactly an hour off (time for them to react to the end of the test and hit the DONE button).  But if there IS a cal operation, the end of the test is recorded, then they fiddle about for 10 minutes, then click DONE, so the discrepancy is less than an hour.   

if you could post some pictures (png) of your code that would really help. 

I don't think so, as it's spread out among various VIs, called at various times,etc.  No picture will make that clear.

It almost sounds like you aren't reading the time in part c when you think you are 

A reasonable thought, but I assure you that the time in part C is read after the DONE button, and the other things are way before it. 

Did you try to wire the get date/time in seconds to the format date/time like I suggested? 

That won't help on my machine (which already works) and I can't run a test on my client's machine just for this (it costs fuel and operator's time). 

Also enabling the UTC checkbox will convert to UTC time which is independent of DST problems. 

What UTC "checkbox" are you referring to? 

[CoastalMaineBird]

FWIW, my client is in CDT, while I'm in EDT.  That's an hour's difference, though I don't see that as causing a problem, since he starts with source code on his machine.

Perhaps his time zone is set wrong.

Even if so, I don't understand why one function would be different from the other. 

[TCPlomp]

---

CoastalMaineBird wrote:

 if it was solely the problem of daylight savings time or UTC differences it would be a matter of hours, not minutes.

if you could post some pictures (png) of your code that would really help. 

I don't think so, as it's spread out among various VIs, called at various times,etc.  No picture will make that clear.

---

Well we could see what exact functions and format strings you are using.

Also what version of LabVIEW are you using? Version 7.0  has not a fully bug-free DST time handling.

How do you see the difference? Is this a string indicator or a Timestamp indicator? Timestamp indicaters can be formatted to show the time absolute (GMT). Or the end user could have adjusted the time and not the DST setting. Those settings are very important for the timestamp display. A timestamp data-point contains a given numder of seconds and fractions of seconds since January 1 1904 midnight. The display interpretes this into a string format.

Ton

[CoastalMaineBird]

Well we could see what exact functions and format strings you are using.

Like I said, I'm recording time A with a GET DATE/TIME IN SECONDS function with unwired inputs:

 

Like I said, I'm recording time B with a GET DATE/TIME IN SECONDS function with unwired inputs: 

Like I said, I'm recording time C with a GET DATE/TIME IN SECONDS function with unwired inputs:  

  

When it's time to assemble the data file, the A and B values are fed out as timestamps...

 

... and put into the file as timestamps:

 

Also what version of LabVIEW are you using? Version 7.0  has not a fully bug-free DST time handling. 

Like I said, I'm using LabVIEW 8.6.1f2

How do you see the difference? Is this a string indicator or a Timestamp indicator? 

A and B are displayed in Timestamp indicators:

 

The only formatting change is that I removed the <return> so that they display on a single line:

 

Item C is displayed in a string indicator (actually an array of them) in the above pic.

As you can see in that last pic, the test ended at 10:59:31, but the "Recorded on" date is almost an hour earlier.

What you CAN'T see from these pictures is whether or not I CALL the pictured functions at the time I am claiming; you'll just have to take my word for that.

The fact that it's (almost) exactly an hour difference in all the files with no post-test CAL operations indicates that it's not that I'm calling the "Recorded ON" function (point C) at 10:00:10, waiting for 40 minutes and then starting the test.

And if that were messed up, it would mess up on my machine as well.

 Timestamp indicaters can be formatted to show the time absolute (GMT).

--- Yes, but I am 5 hours removed from GMT, my client is 6 hours.

 Or the end user could have adjusted the time and not the DST setting.

--- This is what I suspect, but why would that affect one function and NOT the other?

Those settings are very important for the timestamp display. 

--- Are you suggesting that the TIMESTAMP DISPLAY uses them at DISPLAY time?  

Hmmm.

That could explain the discrepancy, I guess.  But, no, it seems like BOTH functions should use them.  If the DST/TimeZone were set wrong, why wouldn't it affect BOTH?