Is DST active for this timestamp?

[Hamilton_Woods]

I am working with an NI-9074 VxWorks cRIO.  I have changed the file, ni-rt.ini, back and forth between RTTarget.TimeZone="CST6CDT" and RTTarget.TimeZone="CST6".  Then I set the system time of the cRIO to different dates through the year.  The timestamp rec always returns DST=0.

I set the cRIO system time using a VI on a Windows 7 computer.  A front panel indicator of a VI running on the cRIO shows an appropriate value from the Get Date/Time in Seconds function.  However, when I format a timestamp value to a string, the time portion of the string is one hour slow when the date is in the summer (when Daylight Savings Time (DST) is active).  Also, NI MAX displays the same (sometimes incorrect) time that the string displays.

I can share a variable between the Windows 7 computer and the cRIO that tells the cRIO whether or not DST is active so the hour can be added or not.  I would like to implement code on the cRIO that does not depend on the Windows 7 computer always being connected to the cRIO.

Lacking a better solution, I propose a VI that can run on the cRIO that determines if DST is active for a given timestamp (based on the 2005/2007 DST rules).  Is one already available?

Thanks for your help.

[JÞB]

Use UTC to exchange time between targets, convert to civil time later. 

(Just saying. I used to be an amature horologist but, please don't tell my wife)

[Hamilton_Woods]

Thanks for your reply.

I am logging unit failures on an NI-9074 cRIO.  Each time a failure occurs, I generate a file that contains

data related to the failure.  The data are 20,000 records of current, voltage, temperature, along

with the current limits for each time point.  The data are being written to a binary file.  Timestamp 

is being recorded as a double (as each of the other "columns" of data).  The name of each

failure data file is unique.  Part of the file name is the timestamp when the failure occurred. 

The timestamped data in the file are being transferred to a Windows 7 computer and processed

normally.  The file name contains a timestamp that is not correct (not what cRIO system time was

set to) when DST is active.  

It is really odd to see a waveform chart in LabVIEW for which the abcissa matches the timestamp 

of the Windows 7 computer on which it is displayed, yet the name of the file contains a timestamp 

that is an hour earlier (this is really odd when it appears that the failure occurred before the test 

started).

Again, indicator on front panel of VI running on cRIO shows time matching what the cRIO system

time was set to.  Strings created from the same timestamp show an hour earlier.  NI-MAX shows

an hour earlier. 

I am working on a routine to adjust a timestamp based on what US Department of Transportation

thinks DST is rather than what cRIO thinks.  From what I can tell, this is only needed when a

timestamp is converted a string and only when the cRIO thinks that DST is different from what

USDOT thinks.

Thanks for your help.

[rolfk]

A LabVIEW timestamp is binary and internally supposed to be ALWAYS in seconds since midnight Jan 1, 1904 GMT. As such you can transfer the binary timestamp (even when converted to a double) between computers and it will remain the same. The difficulty occures when you try to convert the timestamp into local time which is whenever you display it in a timestamp control or more generally when you convert it into a displayable form as human readable string. Here LabVIEW will normally use whatever timezone it currently thinks would apply. Each OS has quite different implementations but generally all modern OSes know about DST and timezones and even about locale dependent changes of the date and time when they change.

Most RT systems however do not have such a complicated implementation (and yes implementing local date/time handling properly for more than a single location and year on this globe is a really cumbersome exercise). Instead they just use what early Unix systems often had, and that is simply a constant timeoffset to UTC/GMT based on a user settable timezone name. You forget to change the timezone setting, you also get wrong time displays. It's a pitta and can be rather problematic but in my opinion it is better to have a minimalistic implementation that leaves the responsibility to get things right on the user than a supposedly complex system that does not always work reliable.

I haven't really come across inconsistencies in how Windows 7 and 8 currently implement timezone handling but there have been many in the past in older Windows versions and my feeling was that it would have been better to have no assumed intelligence at all in this than something that worked sometimes wrong.

An interesting challenge was when a customer who operated all over the globe wanted to log data with timestamps and have the option to display times in ccurrent local time (trivial as that is what LabVIEW will do automatically), UTC (also quite easy since you can since about LabVIEW 8.0 format timestamps into displaying UTC) and the original local time (a complete pitta since that requires you to store a timezone offset with every timestamp or at least frequent enough to not miss timezone changes when switching between DST and normal time and vv. and make an extra offset calculation on each timestamp before formatiing it into fake UTC display). Extra kudo points if you think about a smart way to display the data in a time graph during the time when timezone offset changes occur and the customer decides to want to display everything in either of the two local times.

[Hamilton_Woods]

I have implemented a solution that does what I need (works for most of US).  I use this VI (AdjustForDST) just before converting a timestamp to a string.  When I use this VI, the value of the string matches the value of the timestamp on a cRIO 9074.  Keep in mind that NI-MAX and a web browser will still report a system time that does not match what the system time was set to.

Have a great day.