LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Timestamp system time differences

Solved!
Go to solution

I have an issue with a service partner laptop that is running our Labview based software. We use the software to perform some measurements that store timestamps in a TDMS file. Have been working like this for several years now. These timestamps are usually stored in elapsed time since the standard epoch time (01:00:00 01-01-1904) but for some reason the executable on this laptop has stored them as 31-12-1903. I know this is basically the same time, but the software then sort of messes up. We do some base result calculations in which we calculate starting points. The thing here is if you subtract 01:00:00 01-01-1904 from for instance 01:00:10 31-12-1903, you get a negative number.

Like I said I'm not sure why that laptop stores in a different universal timestamp then the rest of the software, but I have to figure out a way for Labview to adjust these values to a value that we can calculate with. I assume it has to do with a change in timezone settings on the laptop (it's a canadian laptop, we're based in europe).

Our tdms files store all tests done per project and I now have a mix of both 1903 and 1904 in the same tdms files.

 

Is there a simple way to convert a 1903 timestamp to 1904? Or do I have to unbundle each timestamp and manually change them?

0 Kudos
Message 1 of 12
(278 Views)

LabVIEW timestamps are in UTC without any leap seconds.  

 

Timestamp constants do not "Travel" well across timezones since they tend to adjust theirselves to localized time.  Check the format for all timestamp constants and avoid the default %x (local) use %z? (UTC)  it sounds really, really odd to have a 10 second offset! Something on that suspect machine is funky!  Look into the system time settings and check if it has some pirated OS. This should not happen with Genuine Windows.

 

Now, there are some other things that could be happening.   For example,  Excel has an option to change timestamp epoch and increment between the two most common.   Hit up This rejected idea for a bit more details than I have time for now

Scientists STAND on the shoulders of giants! They don't ride "piggyback" to keep their heads down.

"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 12
(257 Views)

I've checked most of the timezone stamps and all appear to be correctly formatted. Like you said, I think something is off with that laptop. FYI it isn't a 10 second offset, it's a 24 hour offset. I'm guessing it has something to do with the DST on that laptop. Like labview somehow shifts a time back from DST that has already shifted back an hour? It's really weird. But what even makes it worse is that I can't just shift the data 1 hour. 
Can anybody think of a way to verify some settings through the system registry when starting the labview exe, to make sure things are as they should be?
I thought about forcing them to put their system on W. Europe Standard Time (where the software is written and most of the data is analyzed), but that might be inconvenient for our overseas partners...

0 Kudos
Message 3 of 12
(214 Views)

I don't know all the ins and outs of timestamp handling and formatting as I've rarely had to contend with an app that needed to correlate data across different time zones.  I did have a long-ago run-in with Daylight Savings though and *that* taught me a few things.

 

So here are some things I see here, in the U.S. Eastern Time Zone, non-DST, formally UTC minus 5 hours.

 

1.  I have a DBL control with value 0.  I wire it to a DBL indicator, with display format set to show absolute time.  I see "19:00:00.00  1903/12/31".   When I send the same value through a "convert to timestamp" and into a timestamp indicator, I see "00:00:00.00  YYYY/MM/DD".

 

2. This seems to be a special behavior of the timestamp display, because if I change the DBL control to -1 (meaning 1 second *before* epoch time), both indicators look identical "18:59:59.00  1903/12/31".  They similarly agree for values of seconds > 0.

 

3. So what's being displayed for me seems to depend on the time zone my OS thinks I'm in.  I'm in zone UTC-5, and I see times of day that are 5 hours earlier than the epoch time reference LabVIEW uses.  To break out of this, I can go into the display format and change to "Advanced editing mode".  There I can choose to display Universal time using a format that looks like:

"%^<%H:%M:%S%2u  %Y/%m/%d>T"

 

   When I use that format, my -1 sec DBL displays as "23:59:59.00  1903-12-31".  

(Note that apparently, the default Universal time format has a hidden linefeed or carriage return in there as a line separator, but I didn't find a way to display it.  In the format string above I deleted it.)

 

4. Is there ever a place in your code where timestamps get recreated from their string representations using a "scan from string" type of function?  Or is any of the saved timestamp data converted to string format before writing?

   Conversions to/from string are problematic because the conversion seems to take account of the system's time zone and DST settings at the moment the conversion is done.  So if you convert from timestamp to string while saving to file on one system, then import the data on a PC in another time zone where you convert back from string to timestamp, you won't get the original timestamp back.

 

I haven't really experimented to understand the implications (if any) of time zones and DST on the Date Time Record format.  Since I simply don't know, I would still consider it another *possible* place where time adjustments and manipulations could be affected by OS system time settings.   Others may be able to inform us more definitively.

 

 

-Kevin P

0 Kudos
Message 4 of 12
(207 Views)

Thank you Kevin, 

 

One of the problems I'm facing is that I want to create a shift on the X axis of a graph. To do so, I convert a timestamp (in this case one of those other system 1903 ones) to a DBL and then insert it into the graph settings. The DBL result is then a negative number, so the whole graph is off around 24 hours in the past.
Another thing is that I'd like to fix that timestamp constant part, but I found out our program features more then 2000 occasions of that timestamp. Most are from typedefs, but I'd still have to check and manually edit each timestamp to that "advanced editing mode". 

 

At the moment I'm waiting on a reply from the field engineer if his system has been changed in the last several months. I've checked the software itself, if I change my location and time settings, this doesn't effect the timestamps (so standard epoch time format).

 

I think it might be something like what JB mentioned where Labview writes the timestamp to the TDMS and in transit it gets changed to the 1903 format.

Trying to look into that right now.

0 Kudos
Message 5 of 12
(202 Views)

@Kevin_Price wrote:

 

Conversions to/from string are problematic because the conversion seems to take account of the system's time zone and DST settings at the moment the conversion is done.  So if you convert from timestamp to string while saving to file on one system, then import the data on a PC in another time zone where you convert back from string to timestamp, you won't get the original timestamp back.


That used to be the case in old LabVIEW versions. Nowadays the timestamp conversions do usually account for the actual timezone and DST setting valid for the actual time in question. This does require according support by the OS and only Windows 7 started to have such support consistently.

 

Conversion from timestamp into string is simpler as the timestamp in LabVIEW is always assumed to contain UTC time so conversion is from a well known linearly (since lap seconds are not really accounted for) increasing time to some other format. The opposite is much trickier to convert consistently.

 

For instance there are problems with conversions, if a timestamp appears to fall into the interval jump caused by switching from and to DST or when a timezone change is declared for a specific region (yes there have been areas assigned to different timezones in the past and most timezone databased including the one used in Windows usually account for that with the date and time of the official switch).

 

Also there is of course the big problem of matching arbitrary timestamp strings from potentially any possible timezone into the timezone of your current system. The time functions usually all assume the timezone for the current system and can't translate other time strings easily, especially since they often don't even contain a timezone information but simply are assumed to be in a certain timezone that the user often doesn't even know of or at least doesn't be aware of that it is in discrepancy with his current system settings.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 6 of 12
(197 Views)
Solution
Accepted by topic author DennisvdH

Thank you! I think I may have found a (slightly blunt instrument) solution. Instead of forcing the stamps to be in the correct timezone, I just check if they are not and replace them with the correct date. The key was what you said about converting to a string. I noticed our program receives the markers as strings from the TDMS, so was somewhat of an easy fix to just change them back to 01/01/1904 at that spot in the script. For now everything appears to function. The calculations between the markers are correct and the offset on the graph as well.
Thanks for helping out!

0 Kudos
Message 7 of 12
(183 Views)

I wonder if that computer has its localization info set up incorrectly?  UTC timestamps should always agree.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 8 of 12
(171 Views)

I haven't had any reply from the engineer yet. I'll get back on that once I have.

0 Kudos
Message 9 of 12
(163 Views)

Hopefully that'll work for the purposes of your particular app.  Just be very careful that you really understand the implications of this kind of hard-coded bandaid.  Your approach may very well be just fine for this app's particular needs, but there are also plenty of scenarios where it *wouldn't* be fine at all.

 

Thanks to rolfk for the correction/clarification about string format conversions.  Indeed the DST problem I referenced, and which sensitized me to string-formatted timestamps in the first place, came back in roughly '06-'07.   At the time we were probably running LV 8.x, mostly on Win XP with a few Win 2000 systems around as well (possibly including the PXI controller in question).

    I was using TDMS for the first time and it didn't yet support the timestamp datatype.  I should have saved the relative seconds as DBL, but instead I naively and wrongly chose to save my "event timestamps" in a string format.

    Anyway, having been burned, I try to avoid string formatting of timestamps in my data records (though I may still use it at times for convenience in text file headers.)

 

 

-Kevin P

0 Kudos
Message 10 of 12
(160 Views)