Time stamp constant changes

[Mark Levine]

So I select a time stamp and set it to a value.  I connect ot a conversion to get number of seconds.

Then I change the time zone on my computer and the time constant changes.

Why does NI call it a constant if it changes value?

The number of seconds remains the same but the hours value changes.

This doesn't seem like the kind of behavior I'd expect.

Thanks,

Mark

[Matthew_Kelton · Accepted solution]

The time constant is Univeral Time.  It is being displayed as the time in your time zone.  So, when you change your time zone, the value doesn't change, but the display of the value changes to the new time zone.  You can change the display format to show UTC instead, and the time won't change.

So the time is a consant (which is evident from the fact the time to secs remained the same).

[Mark Levine]

None the less this drove me nuts. 

Were the time functions always relative to UTC in earlier versions of LabVIEW?

I found some VI software to convert LabVIEW to UNIX Time code that didn't work.  They used the Get Date/Time and the time stamp constant which as you described won't work.  And they used some .dll to get at the time zone offset on the PC.

To get to UNIX Time all you have to do is subtract 2082844800 from the LabVIEW Get Date/Time call.

[Matthew_Kelton]

The time is always referenced to midnight, Jan 1, 1904 UTC in LabVIEW.  Always has been.  In older versions of LabVIEW, there was no timestamp, you only represented it in a DBL.  The Timestamp gives us a display value that makes some more sense.  Again, it is still secs since 12AM Jan 1, 1904.  The standard display is in the current PCs timezone.  If you don't want that, right-click on the constant, choose display format.  Go to Advanced and change the %<....>T to %^<....>T and the consta will display as UTC and will not change.

Unix is referenced to 12AM Jan 1, 1970 UTC.  The number you subtracted should be the difference and is the way I woul do it.  I don't know why someone would use a time constant in that manner, although it should be able to work just fine.

[Mark Levine]

Matthew,

The enclosed algorithm on the left is what I used.  Didn't see "the new and improved algorithm" on the right.

BTW the algorithm on the left DOES NOT WORK as the reviewer indicated. 

[Matthew_Kelton]

I don't know why the orginal author did the left side the way he did.  It it was over complicated and was completely unnecessary.  His biggest issue was that he didn't set the constant to UTC, he incorporated the time zone and then tried to determine the time zone to correct for it.  It is working for me, though, even with a time zone change.

However, the VI I attached greatly simplifies the left hand side by having the constant be at UTC.  If you probe the DBL conversion of the constant, you will see it is the same as the DBL constant on the right hand side.  The two sides are equivalent.  The only plus being that the right hand sign shows the date, so may be a little easier to follow.

[Mark Levine]

Matthew,

Thanks.

I learned how to set the time stamp constant to absolute and that the Get Date/Time is seconds relative to UTC.

I will challenge you on your results using the algorithm I sent you.  It will not work for time zone changes whether you fix the time stamp constant or not.  So long as the program tries to slip in the correction for time zone it can't possibly work.  If you were saying that if you remove that bias it will work then we're in violent agreement.

Mark

[Matthew_Kelton]

Nevermind.  I do see an issue.  I need to get new glasses.

[Matthew_Kelton]

The issue with the original code is it only works in the Central time zone.  Because they did not set the time constant to 12:00AM, Jan 1, 1970 UTC, but rather 12:00AM, Jan 1, 1970 CST, the calculation is off by 6 hours.  Then they call the WinAPI funtion to correct for the time zone difference.  Well, since LV stores time constants as UTC, but displays them in your local timezone, the calculation was always off by 6 hours.

The programmer assumed the timestamp constant would always be in your local timezone, so it would be off by your timezone.  But that assumption was incorrect.

[Matthew_Kelton]

As an aside, I found an annoying LV behavior - LV only checkd time ofsets at startup, so if you change your timezone while LabVIEW is open, it will report your original time zone setting.