cRIO timestamp to string

[WNM]

When a cRIO-9075 first boots, it shows in a TimeStamp indicator, a system time of around 4PM on December 31, 1969.

If I take that timestamp value and pass it into a "Format Date/Time String Function" to get a string representation of the timestamp, the date/time the string gets really messed up. The same code run on a Windows system works flawlessly.

What might be causing the format-stamp-to-string function to fail on the cRIO?

[rolfk · Accepted solution]

What timezone are you in? GMT -8?

This looks like the cRIO gets reset to its Unix January 1, 1970 GMT epoch and there is no time server configured for it to update to the actual time. The Unix timestamp code in LabVIEW can't really deal well with dates before this point of time, as far as Unix is concerned the big bang in which the world was created and computers started to appear happend at this moment

Windows has an epoch of January 1, 1601 and your date of 1969 is way above that and there is absolutely no problem to deal with that date there.

[WNM]

Yes, the system is setup for UTC - 8:00 and what you say must be the reason for the behavior.

I can enter a value of 11:59:59 PM on 12/31/1969 and get a bad conversion to a string (02/06/06  06:28:15.5 PST).

Yet when I enter a value one second later of 12:00:00 AM on 1/1/1970, I get a good string result (01/01/70  00:00:00.5 PST).

[WNM]

One final thought that occurred to me was that if NI can make the TimeStamp indicators smart enough to display the correct time/date on the cRIO for a minus 8 hour (PST) offset from 12:00:00 AM on 1/1/1970, then you think they could also darn well make the timestamp-to-string functions (like "Format Date/Time String") also produce valid date/time strings for the same timestamp values.

[Hooovahh]

---

@WNM wrote:

One final thought that occurred to me was that if NI can make the TimeStamp indicators smart enough to display the correct time/date on the cRIO for a minus 8 hour (PST) offset from 12:00:00 AM on 1/1/1970, then you think they could also darn well make the timestamp-to-string functions (like "Format Date/Time String") also produce valid date/time strings for the same timestamp values.

---

I believe you can.  Here is one such thread where the time is displayed in UTC or in the timezone you are in using the format into string.

https://lavag.org/topic/15034-timestamp-support-for-format-into-string-scan-variant-from-string-stri...

[rolfk]

It's all about different codepaths. When you write software you often end up writing a function to do something. Then a new requirement comes up and you have two choices:

1) Modify the existing function and risk screwing some corner case up that someone at some point in the past did discover either by accident or ignoorance.

2) Write a new function that does what you need and leave the old alone

Do I hear code duplication? Yes of course but the alternative is to either screw something up somewhere with a reasonable chance or never release that feature.

Now go back and use that new function in the other places? Same problem again.