Seconds to Date/Time bug - hour not treated the same on host and cRIO

[Michael_Ross]

I am seeing that the function Seconds to Date/Time operates differently on the host computer than it does on cRIO-9022/cRIO-9114 (using 2010 SP1)

On the both host and cRIO 
using the timestamp

17:05:47.000 (more or less randomly chosen) 
12/5/2012

With the input "to UTC?" wired to a False boolean constant and the output wired to a Timestamp indicator

The hour indicator in this bundle is reported on the host ot be 17 on the cRIO the hour indicator is 22

You can make a simple VI and move it between the host and RT in the project and see the change in response.

I made one for host and one for RT then made a screen dump showing them side by side which is attached.

It apppears to me that in RT the Timestamp is evaluated as if it was in UTC.  The difference of 5 hours is the difference between GMT and EST whcih is my time zone.

This has been a real drag because I developed a sun position calculator on the host and moved it to RT.  I looked at everything else before assuming a malfunction.  Or perhaps it is a malfunction of documentation - there is no warning of this behavior in the help or elswhere that I have seen.

A realted side issue (you can tell I know way to much about this now, that I wish I never knew).

On the subject of documentation, the help regarding the "to UTC?" input is not much help at all.

"is DST returns a value for standard (0) or daylight saving time (1). If to UTC is TRUE, is DST is standard (0). "

It is not clear there is a connection between "to UTC?" and  "Is DST"

In fact, if you set "to UTC?" there is not only the response of DST, the hour reported is also different.

It would be nice to see ithe documentation explain exactly how the outputs follows the inputs:

0700 EDT  to UTC? = F   Hour = 7     DST = 1

0700 EDT  to UTC? = T   Hour = 11   DST = 0

0700 EST  to UTC? = F   Hour = 7     DST = 0

0700 EST  to UTC? = T   Hour = 12   DST = 0

There are four unique results.  It makes sense when you work it all out, but you won't get it from the  documentation the first time you read it.

If it was me wrting the doc I would opt for a table such as that aboven, and some more useful verbiage.

[Michael_Ross]

I falied to netion that "to UTC" has no effect when Seconds to Date/Time is used on RT (or in hybrid mode at least).

In other words, when to UTC? = F, and you send a date and time where EDT is in effect, the DST output does not respond with a 1 as it does when running on a PC.

[rolfk]

It's more complicated than that. You also have to consider the actual DST state of the timestamp. In older LabVIEW versions DST was always the current status. In newer LabVIEW versions DST is related to the actual DST status at the moment the timestamp refers to, but that also depends on actual support from the underlaying OS, which in XP is limited and in W7 is ok, but which I'm very positive the RT targets do not have at all. So any table you come up with will in fact end up with more footnotes about exceptions and caveats than any potential user is willing to put up with ;-).

[Michael_Ross]

Hi Rolf,  a hearty info-LabVIEW greeting,

I think I will just wrok it all out in UTC + 5 and try to remember that I am looking at "not daylight savings" all the time.

It is a real shame that this is so lame.  It can cost a lot of time sorting it out.

I wasn't exactly looking to a help as much as putting it in the forum as a bug report.  I have the impression this is the preffered way to do so.

Mike