How to get correct timestamps on RT controllers

[MemoryGrowth]

I am using a PXI-8106 controller. The time on this RT controller is manually set by RT Set Date and Time. Then, I use Get Date/Time in Seconds to get timestamps. These timestamps are always incorrect by a few hours due to some unnecessary time zone consideration. If I use Get Date/Time String, it shows the correct time but I need correct timestamps, not strings. I tried to convert the strings back to timestamps but I got the wrong time again. Is there any standard or generic way to deal with this?

Relevant article:

The Current Time is Incorrect on My LabVIEW Real-Time Controller

[RobCole]

If you are using RTOS, go into MAX and connect to your PXI controller. Switch tabs to get to the time settings and set it to your local timezone. This will solve the problem.

If you are using Windows on the PXI, right click on the time in the bottom right and select Adjust Date/Time to set the timezone.

You other choice is to leave the PXI on UTC timezone and adjust the PXI clock to be UTC time. There are other issues this can cause (data saved on the PXI will have the UTC timestamp).

If you are using a computer to talk to the PXI, LabVIEW will automatically adjust timestamps when moving them from the PXI to the computer (or vice versa) based on the timezone set on each system.

Rob

[rolfk]

---

@Robert Cole wrote:
 

If you are using a computer to talk to the PXI, LabVIEW will automatically adjust timestamps when moving them from the PXI to the computer (or vice versa) based on the timezone set on each system.

Rob

---

That might be a bit misleading. LabVIEW does no timestamp correction of any sorts like your message implies. LabVIEW timestamps are simply a number of seconds since midnight Jan 4, 1904 UTC. So they are always related to UTC. Considering that the clock on two systems is set right, a timestamp on system 1 will be the same on the second system independent of any timezone settings. It's in the interpretation of the timestamp into a printable time string where timezones get into the game and can mess up a lot. And by default LabVIEW always uses the timezone to translate a timestamp into a local time string, which if the system from which the timestamp comes is located in a different timezone, will show the local time at the displaying system at the moment when the timestamp was generated on the remote system.

[RobCole]

---

@rolfk wrote:

---

That might be a bit misleading. LabVIEW does no timestamp correction of any sorts like your message implies. LabVIEW timestamps are simply a number of seconds since midnight Jan 4, 1904 UTC. So they are always related to UTC. Considering that the clock on two systems is set right, a timestamp on system 1 will be the same on the second system independent of any timezone settings. It's in the interpretation of the timestamp into a printable time string where timezones get into the game and can mess up a lot. And by default LabVIEW always uses the timezone to translate a timestamp into a local time string, which if the system from which the timestamp comes is located in a different timezone, will show the local time at the displaying system at the moment when the timestamp was generated on the remote system.

---

You are correct. It is when timestamps are displayed or converted to string that the translation happens. The problem comes if the RT is set for the UTC timezone but you set the time to your local time. If you use MAX to set the time, there is no translation from the PC's time to UTC. Same holds true if you set the PC time on the RT with RT Set Date and Time.vi. When data is moved as a timestamp to the PC and viewed, it will be out by the number of hours in your timezone.

I believe whether or not the system adjusts for the local timezone should be an option. This is from systems transferring data via satellite across timezones and the difficulty in knowing what the time at the origin was (the systems were mobile and crossed timezones regularly). Time data had to be sent as strings.

Rob

[PhillipBrooks]

See my signature for a way to convert timestamps to and from ISO 8601 compliant strings.

%^<%Y-%m-%dT%H:%M:%S%3uZ>T

[rolfk]

Since about LabVIEW 8 you have a lot more control if the timestamp to string operations should adjust for timezone or not.

The timeformatting code %^< >T both in the Format into String, as well as in the Advanced Number format settings of a control support UTC formats, which will not use any timezone in effect.

[MemoryGrowth]

Thanks for the comments. The time zone on my PC and the time zone on the PXI (MAX) are the same now. Eastern Time (UTC -5) with DTS on. What I wanted to know is how to take the time on the PXI clock as the face value and print it as it is no matter where you open the TDMS file. This has to be done using the timestamp format, not string, because some module has to use timestamp input. The RT unit can travel around the world to do its job and the PCs reading TDMS files can be in different time zones. I tried different codes but they didn't work very well. Could someone actually post a simple code here?

I have another question, Is there any known lagging issue with the PXI's internal clock? Yesterday, I set the PXI's time using RT Set Date and Time. I made sure it's within 1 second difference from my PC clock. This morning, the time on MAX was 5 seconds behind my PC's clock. The controller's clock seems to lag slowly over time. Someone told me that after a few months he noticed there was a huge time lag on his RT controller. Is this normally expected?

[rolfk]

Well if you store the timestamp in a TDMS file as timestamp and not as string it will always store the UTC value. A timestamp itself can't really be anything else but UTC (unless you do some magic to it yourself, but that is the equivalent of taking apart a device and loosing all warrenty). If you store it as a string, then you have to apply the correct formating at that moment.

[RobCole]

Ah yes, this reminds me of this thread on RT timing.

The problem used to be much more pronounced, but it is still a problem.

Rob

[RobCole]

Oh, and here is a little VI I found a while ago for how to find what the timezone of a timestamp is. You can also run it with Get Date/Time in Seconds to find the timezone of the PC (or RT) system running it.

You may have to do some math to display the time from the originating system.

Rob

p.s. I added offset in seconds for calculation and because Canada has one timezone on the HALF hour instead of the hour.