The TIMESTAMP indicator is smart enough to get you into trouble.

Just ran into what at first appeared to be a bug, but turned out to be proper, if misunderstood, behavior.

I have a project which records data files. When the actual recording starts, and again when it stops, I remember the time (by using a GET DATE/TIME in SECONDS function) in a TIMESTAMP variable, which is stored in the data file. There might or might not be some calibration activity after the recording has stopped.  When the DONE button is finally clicked, I record the current time using a FORMAT DATE and TIME STRING function, into another string field called “TEST TIME”

I have a viewer which examines the data files and reports various info about them. The indicator that shows the TEST TIME is on a different window from the one that shows the START TIME and END TIME.

If there’s no CAL operations done, then the TEST TIME has always been just a few seconds later than the STOP time (enough time to react to the test being done and click the DONE button), or it could be a few minutes later.

However, I recently noticed that, on a data file sent from my client to me, that the TEST TIME was almost an hour EARLIER than the STOP time.  How could that be?  Further rummaging thru other files that I had from him shows the same thing: the TEST TIME was short of an hour EARLIER than the DONE time.  If there were CAL operations done, this difference was 45-55 minutes; if not, it was a few seconds short of an hour.

I have run thousands of tests on my machine without noticing this; my client has also run nearly a thousand, and has never brought it up.  Why is that?

There’s one piece of info missing from the above description that’s critical to figuring out what’s happening: My client is on CENTRAL time, while I am on EASTERN time.

It took a while to figure out what was really happening:  The TIMESTAMP value was being sent whole: encoded with that value somewhere must be the TIMEZONE that it was recorded in.  When the file crossed the timezone line, the value (as it was displayed to me) actually changed.  I confirmed this with my client; a given file showed a START time of 9:39:20 on his machine, but the same file showed a START time of 10:39:20 on my machine.  Of course, those are the exact same moments, just expressed in different time zones.

The TEST TIME, however was recorded as a STRING, and as such, has no mechanism for changing.