Format Date/Time String always returns UTC on cRIO 9038

[clendon.gibson@canrig.com]

Hi Folks,

I am trying to get confirmation of a bug. What I am seeing is that the Format Date/Time String always returns UTC when deployed on a cRIO (or at least a 9038 cRIO) whether the boolean input to select UTC is true or false.

The function works fine on Windows.

A code snippet shows the example I use to demonstrate this. Depending on where you are in the world, the following code will show two different times. The "date/time string" will show UTC wherever you are are despite the UTC option being set to F. (Setting it to true doesn't help.) The "current time" will show your local time.

If this is a bug, where would I report it?

Thanks!

[RavensFan]

Reporting here is just fine if this is a bug.  An NI employee should see it and submit a CAR # for it.

But is this a bug?

What is your target of execution?  I'm going to assume you are running this on the cRIO itself.  If so, is there a setting on the cRIO where you can tell it what your local time zone is?  Obviously in Windows you can set the local time zone.  But I don't know if you can do that on a cRIO.

EDIT:  This article seem to indicate you can set the time zone on the cRIO. https://decibel.ni.com/content/thread/1942

So the next question is whether the time zone has been set.

[clendon.gibson@canrig.com]

Hi RavensFan,

I'm not sure about all cRIOs, but the cRIO in question, a cRIO 9038, supports setting the time and time zone. You can do this either through NI MAX, or by going to the cRIO configuration web page. (Which is simply http://IPAddress)

Here is the screen shot from the cRIO config web page of the cRIO I am using:

[Sam_Sharp]

Did you see this article? http://digital.ni.com/public.nsf/allkb/E9D08C9F795FF49F86256F9000040DC9

In short - a timestamp indicator will always show the time in the timezone of the target that is displaying the front panel (e.g. you're probably running your RT VI from your Host PC), even for an RT target. If you try using a 'format into string' with both the %<>T and %^<>T (the ^ says to format in UTC), does it show the correct times for UTC vs Local time?

[clendon.gibson@canrig.com]

Hi Sam_Sharp,

This is an interesting article and definitely sheds light on how time works on the cRIO. My problem with it is that the computer I am using and the cRIO are set to the same time zone. There times are also within a minute of each other.

I didn't explain earlier since I thought the code snippet covered it, but the code is used to create a log file name. We noticed the problem when log files were being written with time stamps in the file name hours different then when they collected the data. It seems like the fact that the display is interpreted by the PC's local clock settings would not affect the file name creation. It's true that trying to debug this issue I am running from a LabVIEW environment on a PC. This is not the case in the field where the problem was first observed.

As a further point, the boolean on the Format Date/Time string that selects the output as UTC or not, has no effect on the output when it is running on a cRIO.

I tried using Format Into String with the %T and %^T. In the cRIO, these returned the same UTC result. When run on the PC, they showed the expected behaviour.

[ErikL68]

Sorry to add to this old post so long after it originated, but this bug still exists in LV 2019SP1. Any chance somebody is working on it?

[rolfk]

---

@ErikL68 wrote:

Sorry to add to this old post so long after it originated, but this bug still exists in LV 2019SP1. Any chance somebody is working on it?

---

Most likely not. I have a cRIO-9035 here and can't reproduce anything that resembles a bug as described in this thread.

[ErikL68]

Argh - sorry about that. I discovered our IT department changed the IP address of our NTP server (and then discovered they block the NIST NTP servers), so my unit had its clock wrong due to setting the Time, Date & Time Zone in NI-MAX, resulting in a 1 hour error due to having code to handle the VxWorks cRIO DST issue in the system. I recently restarted using an old cRIO system and didn't check with IT if they had changed anything. After getting the new NTP server IP address, the clock is fine now (thanks to that DST "fixer" code). Regarding DST, see here: NI CRIO 9076 and Daylight savings time - NI Community or keep reading.

I've attached a "quickie" project that I used to test the issue, that just looks at the cRIO clock (& the "Format Date & Time to String" and "Get Date/Time String" functions) I was using to test it. The project contains the "DST fix" function which might prove useful to anyone stumbling on this post.

Here's what I saw during testing:

Looking at the Network Shared Variables in the attached test project using NI Distributed System Manager, the Time Zone issue I was looking for were not found, but the DST issue was confirmed. Three configurations were tested: Using an NTP server, configuring to use an NTP server but using an inaccessible IP address, and not using NTP at all. In all cases, NI-MAX was used to set the Time Zone. After each NI RT.INI file change to change the time sync config, the cRIO was restarted (required for these to take affect).

Note - all testing was done on 6/8/2021, with DST in effect:

Case 1: Valid NTP server, Time Zone set correctly in NI-MAX, but time & date set to a random values in NI-MAX before restarting cRIO:

• Time displayed in NI-MAX: One hour BEHIND
• Raw Timestamp: Correct
• UTC time to String: Correct
• Local Date & Time string: One hour BEHIND.
• Using Get Date/Time String: One hour BEHIND.
• DST-corrected Local Date & Time converted to string: Correct

Case 2: Invalid NTP server IP address, date & time were set to current local time in NI-MAX and "SAVE" clicked to apply clock settings after cRIO was restarted:

• Time displayed in NI-MAX: Correct
• Raw Timestamp: 1 hour AHEAD
• UTC time to String: 1 hour AHEAD
• Local Date & Time to String: Correct
• Using Get Date/Time String: Correct
• DST-corrected Local Date & Time converted to String: 1 hour AHEAD

Case 3: cRIO set up to not use NTP server, date & time set to current local time in NI-MAX and "SAVE" clicked to apply clock settings after cRIO was restarted:

• Time displayed in NI-MAX: Correct
• Raw Timestamp: 1 hour AHEAD
• UTC time to String: 1 hour AHEAD
• Local Date & Time to String: Correct
• Using Get Date/Time String: Correct
• DST-corrected Local Date & Time converted to String: 1 hour AHEAD

Results show that the NI-MAX time is consistent with the Local Date & Time when gotten from the Get Date/Time in Seconds function and then through the Format Date/Time String or the Get Date/Time String functions. If Daylight Savings is in effect, these two functions give the wrong result though, as the UTC Time, Raw Timestamp, and the DST-Corrected Format Date/Time String function are all correct if the cRIO clock is set correctly (by the NTP server).

So... as Daylight Saving is NOT HANDLED AT ALL by cRIOs running VxWorks (see linked forum post above), try to use NTP Servers to set the clock on your device, and only set the Time Zone in NI-MAX. If NTP isn't an option, then set the clock in NI-MAX as though it were not daylight savings. That is, if it's 2 PM Daylight Savings, set it to 3 PM in NI-MAX to get it set correctly, then use the DST Correction code to correct for it. Setting it to the current time (2 PM in this example) will result in a 1 hour error when Daylight Savings ends.