A strange behaviour on two of LV's time VIs

[Xu]

Hi,

I observed a strange behaviour on two of LV's time VIs, "Seconds To Date/Time" and "Format Date/Time String". With different range of number of seconds as input, the VIs behave differently.

Attatched is the test VI in LabVIEW v7.1 running on Windows XP. The test steps:
1. Open and run test vi in LabVIEW development environment.
2. Before click OK button in the popup message box, change and apply timezone setting of Windwos XP to a different bias.
3. Click OK button in the message box.
Result:
For the number of seconds that have elapsed since 12:00 a.m., January 1, 1904 on and before December 31, 1969, the VI's time output changes when the timezone setting of Windows XP changes. But for that on and after January 1, 1970, the VI's time output does not change when the timezone setting changes.
I think it is a abnormal behaviour (a bug). Could anyone give an explanation?
Thanks,

Xu

[tst]

This includes a bit of guessing, and I'd be happy if any of the experts could confirm/correct/clarify.

The importance of 01/01/1970 00:00:00 is that it is the t0 for the UTC standard, which is used by windows (if I'm not mistaken) and by the PC manufacturers in their internal clock (I think). You can see this if you reset a Fieldpoint module or a computer, for example. The date will be 01/01/1970.
Anyway, I don't know how UTC represents dates earlier than 1970, but appearantly these VIs take their timezone from the system and are affected by it. I still find it a bit weird, because I'd expect LV to handle all time calculations internally by its own timestamp format.

[Philip_Courtois]

Hi Xu,

The behavior is interesting. We know that you have to restart LabVIEW to see the changes of the timezone settings, but what surprises me is that you DON'T have to restart LabVIEW for dates before 01/01-1970.

I passed on this information to the LabVIEW R&D team. Meanwhile you might just make sure to restart LabVIEW to see changes of the timezone.

Good catch!

[Xu]

Hi,

Thank you all for reply.
I have worked out a solution to see the changes of the timezone settings without restart LV.
Let number zero as the input for "Seconds To Date/Time" vi, the output time is the current timezone offset.

Thanks,

Xu

[rolfk]

tst wrote:

> This includes a bit of guessing, and I'd be happy if any of the experts could
> confirm/correct/clarify.<br><br>The importance of 01/01/1970 00:00:00 is that
> it is the t0 for the UTC standard, which is used by windows (if I'm not mistaken)
> and by the PC manufacturers in their internal clock (I think).

UTC itself is not really limited by any specific base time. It is mostly
a common nomination and coincidentially is similar to the old GMT,
although I believe account for leap seconds is different between the two
and it specifically excludes any adjustements for daylight saving time.

For the rest you are pretty close but not entirely. 01/01/1970 00:00:00
UTC is the time base of most ANSI C runtime implementations. ANSI C
suggests this date as an example but explicitedly refrains from
requiring any specific date for the time base.
The Windows 32bit API has a system time (FILETIME) which is based on
01/01/1601 00:00:00 UTC with a time resolution of 100ns.

> Anyway, I don't know how UTC represents dates earlier than 1970, but appearantly
> these VIs take their timezone from the system and are affected by it. I still find
> it a bit weird, because I'd expect LV to handle all time calculations internally by
> its own timestamp format.

This has something to do with modifications to the timezone handling in
or around LabVIEW 7.0. Before that LabVIEW always used the timezone
settings of the timezone as valid on the current moment to calculate
between local time format and its UTC second timestamp. This was ok for
current timestamps but did get wrong whenever you tried to look at
timestamps which were in a period which had not the same DST status.
Since LabVIEW 7.0 LabVIEW actually takes into account the real DST
status of the timestamp itself. Well sort of it actually switches on
00.00 of the day the DST starts and stops whereas this is most comonly
done between 2.00 and 3.00.
However not so for timestamps before 1970 and I think this was done on
purpose. Because older LabVIEW libraries used the trick with the 0
seconds (well really 86400 to account for timezones which have negative
offset) conversion to determine the actual timezone offset. If LabVIEW
7.0 would have changed the DST calculation offset behaviour for the
entire time range, proper calculation of the current timezone offset
would have been impossible as LabVIEW would always assume non-DST for
January 2 of 1904 in that case.

Rolf Kalbermatter

[tst]

Thanks Rolf.
Very enlightning.
Nice to have people around who know what they're talking about.