Timestamp conversion different in LabVIEW 8

[RobCole]

Okay, first a little background as to what we're trying to do...

We have mobile systems so we have them set up on UTC. Any of a number of different other systems can connect to these and these other systems can be in any timezone. For various reasons that I won't go into here, we ended up building a method to convert these timestamps (the "automatic" conversion built into LabVIEW was working as we wanted).

So here's the problem: We are converting from LabVIEW 7.1 to LabVIEW 8.0 and the timestamp conversion is DIFFERENT.

Just letting LabVIEW convert timestamps automatically is giving incorrect times in some areas. I was testing for our customers in Saskatchewan (Central Time zone with NO daylight savings time change) and found that LabVIEW was always applying the DST conversion even after I switched off DST conversion in Windoze *and* rebooted my computer.

Our little utility for finding timezone (I have attached a super simplified version here that works west of prime meridian) in LV 7.1 reported my timezone as -7 in standard time and -6 in DST (making it easy to adjust times).  In LV 8.0+, it always reports my timezone as -7. The "is DST" output from Seconds to Date/Time.vi  is always 1 if you are in that time of the year (whether you make the conversion or not).

I am resigned to the fact that I have to change the program (luckily just one sub-VI for the whole system to change), but how do I read whether I should do the DST conversion or not?

     Rob

[rolfk]

---

@Robert Cole wrote:
Okay, first a little background as to what we're trying to do...

We have mobile systems so we have them set up on UTC. Any of a number of different other systems can connect to these and these other systems can be in any timezone. For various reasons that I won't go into here, we ended up building a method to convert these timestamps (the "automatic" conversion built into LabVIEW was working as we wanted).

So here's the problem: We are converting from LabVIEW 7.1 to LabVIEW 8.0 and the timestamp conversion is DIFFERENT.

Just letting LabVIEW convert timestamps automatically is giving incorrect times in some areas. I was testing for our customers in Saskatchewan (Central Time zone with NO daylight savings time change) and found that LabVIEW was always applying the DST conversion even after I switched off DST conversion in Windoze *and* rebooted my computer.

Our little utility for finding timezone (I have attached a super simplified version here that works west of prime meridian) in LV 7.1 reported my timezone as -7 in standard time and -6 in DST (making it easy to adjust times).  In LV 8.0+, it always reports my timezone as -7. The "is DST" output from Seconds to Date/Time.vi  is always 1 if you are in that time of the year (whether you make the conversion or not).

I am resigned to the fact that I have to change the program (luckily just one sub-VI for the whole system to change), but how do I read whether I should do the DST conversion or not?

     Rob

---

I haven't really dealt with timestamp conversions in LabVIEW 8 yet but in LabVIEW 7 there already was a specific issue. If you tried to calculate the timezone offset of a timestamp before LabVIEW 7 you always got current DST status applied. In LabVIEW 7 this was "improved" that calculating the timezone offset of an actual timestamp used the timezone offset that was in effect at the time of the timestamp. However for timestamps before 1970 the old behaviour of applying the current DST status was used (observed and checked under Windows only, sorry)

Could that be an issue you are seeing or did LabVIEW 8 revert to the pre 7.0 behaviour (which would be a bug in my opinion)?

Rolf Kalbermatter

[RobCole]

What I am saying is that LV 8.0+ does not account for DST *at all*.  If I take a timestamp from another system that is using UCT (like an RT system using its default)I and look at that timestamp on my computer, the time shifts by 7 hours. When this timezone is in DST, the time should shift by 6 hours but it *always* shifts by 7 hours.

LabVIEW 7 did it correctly.

I have not, yet, found a method of telling if a timestamp should be adjusted for DST. Not all timezones or portions of timezones use DST. I would prefer not to rely on calls to Windoze to make this determination (there are other operating systems out here).

     Rob

[GMS]

Is that still an issue for you?

[RobCole]

Sorry to take so long to reply to this, but with the change to DST coming up, this has, again reared its ugly head.

This is still an issue.

I think I have finally managed to come up with a VI that demonstrates this problem (I will be taking this up with NI again as well) .

There are a lot of instructions on the front of the VI, so I will not reproduce ALL of them here - just a select few pertinent points.

The date/time record always shows that you are in DST during those periods even when the computer is set to not adjust for DST. In Canada, this happens in the province of Saskatchewan -they do not adjust for DST.

An RT system that is set to UTC, always has the DST element set to 0, meaning that converting one of these timestamps on a local computer that IS in DST is out by one hour.

The VI I have included here lets you chage the month (before or after a DST change) and the DST settings to see what happens. I have set my computer (through the Windows utility) to not adjust for DST in order to emulate what happens in Saskatchewan (an, yes, I rebooted the computer afterwards to see if it makes a difference).

      Rob

[JÞB]

The %Z and %z format specifiers are kind of hidden in the help.  Try this on for size

I've never tested this vi in SK so --- if it doesn't work I'd like to know

Message Edited by Jeff Bohrer on 03-03-2010 04:49 PM

[RobCole]

We use %z to figure out what timezone we are in. That works except for the people in Saskatchewan (we deploy systems there). It will still adjust for DST even when the computer is set to not adjust for DST.

The other issue is that we take a timestamp (from RT) in a cluster flatten it to string and send it to the computer. The DST value in the timestamp reads 0 (which is okay since it came from a system that does not use DST). Converting this to local time on the computer requires extra steps to find out what the DST value should be for the computer (get a local timestamp, extract DST value and inject it into the RT timestamp so that it will convert properly. Either that or convert all timestamps to numeric and add the timezone offset (found using the %z format specifier).

Just taking the timestamp from the cluster and displaying it does not work. This is where we end up out by one hour.

I know - these are actually two different issues. One from RT and one for a computer with DST turned off.

     Rob

[JÞB]

Why is DST turned OFF

Use The local timezone with no DST

OK so I Timewarped my machine to August in CCST (Canadian Central Std Time)

Thusly and tried out my VI.

CCST-6:00:00 and DST=0

Message Edited by Jeff Bohrer on 03-03-2010 05:26 PM