Strange Time Behavior

[B Chavez]

I was playing around with timestamps and found this strange behavior. If I take the two DBL values: 2082844800 and 2082848400 (3600 sec difference) and convert them to timestamp, they both show the same time (5:00:00 PM 12/31/1969 PST). Does anyone know if there was a "Leap Hour" at the end of 1969?

I've searched the web a little bit and found that in the 1970s the world standards switched from "GMT" time to Atomic Time, or "UTC" time (Coordinated Universal Time). But I could not find anything relating to an extra hour.

Just wondering if anyone knows anything about this.

Thanks.

Download File:post-1591-1153108005.vi

[Yair]

This apparently has to do with a change LV made to the time handling after 1969 in LV 7.0. I don't remember (or really understand ) the details, but if you search rolfk's posts, either here or in the NI forums, you should probably find an explanation.

[Ulrich]

This apparently has to do with a change LV made to the time handling after 1969 in LV 7.0. I don't remember (or really understand ) the details, but if you search rolfk's posts, either here or in the NI forums, you should probably find an explanation.

Hello,

When I run this VI, I get one hour difference, from 1:00:00 AM 1/1/1970 to 2:00:00 AM 1/1/1970.

My PC has the GMT+1 timezone (I've tried other timezones with the same result)

Have a nice day

Ulrich

[B Chavez]

Yeah, I tried other timezones with no results as well. It seems it is related to Daylight savings time. If I change my PC date to February, I get the 1 hour difference as you would expect.

[Rolf Kalbermatter]

Yeah, I tried other timezones with no results as well. It seems it is related to Daylight savings time. If I change my PC date to February, I get the 1 hour difference as you would expect.

I haven't checked into this issue specifically but as yen says it's most probably related to how LabVIEW accounts for day ligt saving time correction of timestamps. Traditionally LabVIEW has always used the current times dayligth saving time to convert from its internal UTC timestamp to local time and vice versa. In LabVIEW 7.0 they introduced the ability to account for the DST status of the actual timestamp.

For certain reasons that have not been confirmed by an insider to me, they decided however to keep the old behaviour for timestamps before January 1, 1970. There are two possible reasons I can think of (and they may be actually both true):

1) The OS support for determining if a certain timestamp is DST or not is not (on all LabVIEW platforms?) available for timestamps prior to that date. In order to keep LabVIEW consistent across platforms this behaviour has been chosen.

2) For backwards compatibility! Some Toolkits (Internet Toolkit for instance) use the conversion of 24 * 3600 seconds into a date to determine the current timezonde offset including DST status eventhough that timestamp is of course January 2, 1904 and therefore never could have DST.

Rolf Kalbermatter