Conversion of time-stamp into string produce 1 h offset

[Wiebe@CARYA]

Not sure if this is relavant... If I recall correctly, the DST settings of
windows are not updated in LabVIEW untill you restart LabVIEW. The UTC
offset is updated when you apply it in windows. You might go nuts testing
this (I've struggeled with it a few times)...

Regards,

Wiebe.

[TCPlomp]

I recently checked LabVIEW 8.5 (or 8.2) and a change in the system clock gets updated. Not sure about DST.
But DST behaviour has been improved over the LabVIEW versions.

Ton

[Olli]

Hello Matthew,
many thanks for your suggestions and the description of your experience with the fieldpoints! And of course thanks to the other answers, too. This discussion leads me in the direction, that I will refer everything in the measurement network to UTC and for publication of the data doing the conversion to local time...this seems to be less vulnerable
Also in our application it is not important to have a big accuracy in absolute time synchronisation, but the sequence is important. Therefore one fieldpoint triggers all the other devices by sending a string over the ethernet (virtual private network configuration, no disturbance detected yet).
I never noticed a divergence between the fieldpoint time-stamp and the PXI, when I configured it as time-server. For the other instruments (Keithley 2701E) I synchronise their clocks every hour via command line, because they drift like hell (several minutes per day). I keep their time-stamp only  for information.
The time-stamp accuracy should be within a few seconds range.
Ciao
Olli