timezone offset for dst in LabVIEW 8.5

[rolfk]

I think there is a "bug" in LabVIEW 8.5.1 and probably 8.5 too. I used to have an application that was transmitting timestamp data between computers in some sort of HTTP protocol. The server application has been build in LabVIEW 7.1 and remains in that version for various reasons.

Now the timestamps are transmitted as UTC formatted strings according to RFC1123. In order to do that I used an old function developed in LabVIEW 6.x or so that calculates the current timezone offset from a timestamp value of 86400 seconds (eg. Jan 2, 1904, 12:00:00 AM GMT). Turning that into a date time rec I observed the actual day, hours and minutes to calculate the timezone offset.

With LabVIEW 7.1 the timestamps in LabVIEW started to use the actual timezone offset valid for the timestamp except if that timestamp was earlier than 1970 in which case it still used the current timezone offset as it did before.

LabVIEW 8.5(.1) apparently changed that behaviour to always use the timezone offset of the actual timestamp and since 2 Jan 1904 was probably in every country (at least on the northern hemisphere) non-DST it now gives a different timezone offset than it used to do since the beginning of LabVIEW 2.5. This is cause me an hour or two of debugging :-(.

Of course the new >= 8.0 solution to calculate the timezone offset is now to convert a current timestamp into a non-UTC date time rec and convert that date time rec back into a timestamp telling it that it is a UTC record and then subtract the original timestamp from that.

I would expect the Internet Toolkit to have that same problem unless it has been adapted for LabVIEW 8.5, since my original routine was at some point "loaned" from that toolkit.

Rolf Kalbermatter                            


Message Edited by rolfk on 06-13-2008 02:59 PM

[jimfoxy]

I had a similar problem. I thought it was an intentional feature.

I frequently work with GMT date & timestamped data as an int/double number of seconds or hours. Is there a sensible philosophy of displaying such data on a graph (with X-axis selected as 'Absolute time') without having to first convert the times into system timezone-dependent numbers? What I am doing at the moment is reading the GMT data in, converting it into timezone dependent values to display and manipulate (by applying the method above), then converting the results back again in order to output correct GMT to various files.

I always find it hard to work with time in Labview because you need to keep a close eye on local system timezone settings, unless you ensure that you set the PC's clock to GMT non-daylight savings (not an option for me). It is great that there is now an on/off UTC option for some of the time related VIs.

I don't want to mess around with timestamp datatype because I need to perform manipulation such as division and can't get that to work with timestamps.

Thanks.

[James_W]

"LabVIEW 8.5(.1) apparently changed that behaviour to always use the timezone offset of the actual timestamp and since 2 Jan 1904 was probably in every country (at least on the northern hemisphere) non-DST"

DST really seems to be implemented by politicians at times of political need, e.g. WW1 & WW2, or to meet energy requirements in the case of the US. Most countries did not have DST until post WW2.

see below.

http://en.wikipedia.org/wiki/Daylight_saving_time_around_the_world

(Major bug)

[rolfk]

---

jimfoxy wrote:

I had a similar problem. I thought it was an intentional feature.

I frequently work with GMT date & timestamped data as an int/double number of seconds or hours. Is there a sensible philosophy of displaying such data on a graph (with X-axis selected as 'Absolute time') without having to first convert the times into system timezone-dependent numbers? What I am doing at the moment is reading the GMT data in, converting it into timezone dependent values to display and manipulate (by applying the method above), then converting the results back again in order to output correct GMT to various files.

I always find it hard to work with time in Labview because you need to keep a close eye on local system timezone settings, unless you ensure that you set the PC's clock to GMT non-daylight savings (not an option for me). It is great that there is now an on/off UTC option for some of the time related VIs.

I don't want to mess around with timestamp datatype because I need to perform manipulation such as division and can't get that to work with timestamps.

Thanks.

---

It is not a LabVIEW problem really but simply a problem of any application running on a localized date/time system. And since time in any other form than SI normalized is a ratherbeasty thing, it gets troublesome to deal with it in software.

Rolf Kalbermatter