Format Date/Time to String -3 Hours offset to Windows System time

[MarkusWo]

Hi !
 
When I use the Format Date/Time String VI, the time has an timeoffset of -3 hours to the Windows System time (OS: Windows XP). I use LabView 8.0.
Please advice me what I am doing wrong.
 
THANKS
 
Markus

[IngoS]

Did you wire a True constant to the UTC input? This would convert the local time to a universal time, explaining the difference: UTC format specifies if the output string is in Universal Time
or in the configured time zone for the computer. If TRUE, date/time
string is in Universal Time. The default is FALSE.

[IngoS]

Did you wire a True constant to the UTC input? This would convert the local time to a universal time, explaining the difference: UTC format specifies if the output string is in Universal Time
or in the configured time zone for the computer. If TRUE, date/time
string is in Universal Time. The default is FALSE.

[MarkusWo]

Unfortunately  I haven´t connect any constant to the VI (I use the default values). I have only connect the String terminal. When I debug the program and watch the String output I get the string "03.07.2006 11:48:55" but the Windows System time is 14:48. System time setting is GMT + 1hour (Amsterdam, Berlin,....).
What else could be the reason for this time offset.
Thank you in advance.
 
 

[MarkusWo]

first of all thank you for your help. I have attached a Vi called FormatTime.vi and a screenshot (formattime.pdf) with a probe window. Please have a look on the time displayed in the window and the system time in the status line of Windows XP in the right corner. here you can see the time offset.
BR Markus
 


FormatTime.vi:
http://forums.ni.com/attachments/ni/170/193551/1/FormatTime.vi


formatTime.pdf:
http://forums.ni.com/attachments/ni/170/193551/2/formatTime.pdf

[rolfk]

MarkusWo wrote:
first of all thank you for your help. I have attached a Vi called
FormatTime.vi and a screenshot (formattime.pdf) with a probe
window. Please have a look on the time displayed in the window and the
system time in the status line of Windows XP in the right corner. here
you can see the time offset.
BR MarkusI can confirm that this VI works fine
on my system: Windows XP SP2, latest patchs applied, with Amsterdam
time zone (GMT +1 hour).

It seems that your Windows system is somewhat messed up. LabVIEW
positively makes use of WinAPI functions to access the system time but
I'm not exactly sure which function it uses to account for the timezone
offset. Apparantly there is a mismatch in your configuration somewhere
that causes this function to return inconsistent infromation to LabVIEW.

Have you tried to use the Get Date/Time in Seconds function and see
what the timestamp control displays. There is a change that the
conversion is not done through exactly the same code path and that you
see a difference here, which might help NI to find the problem better.

Rolf Kalbermatter

[MarkusWo]

Hello !
 
first I tried the Get Date/Time in seconds VI. The result is the same as with the date/time to string command (-3 hours offset).
Furthermore I used the VBS function msgbox now. Here I got the the same time as the windows system time.
Have a look on the screenshot attached.
Note: A change of the windows timezone have no effect on the LV result.
I read that there are two different WinAPI time functions, one is called getsystemtime and getlocaltime.Maybe LV use the other than VBS. I can´t tested this functions since I am not familiar with API calls in LV.
 
Markus Woehrle


formatTime2.pdf:
http://forums.ni.com/attachments/ni/170/193744/1/formatTime2.pdf

[tbd]

Hi Markus,
      It's concievable you may find this VI useful.  It decomposes LabVIEW time (seconds since 1/1/1904) Year, Month, Day, etc.  It's useful for building timestamps that are independent of LabVIEW's timestamp functions.  Note, however, no attempt is made to accommodate DST shifts!
 Message Edited by tbd on 07-07-2006 02:17 AM


Util.Time.LabVIEWToYYMMDDhhmmss.ms.vi:
http://forums.ni.com/attachments/ni/170/193949/2/Util.Time.LabVIEWToYYMMDDhhmmss.ms.vi

[rolfk]

tbd wrote:

Hi Markus,
      It's concievable you may find this
VI useful.  It decomposes LabVIEW time (seconds since
1/1/1904) Year, Month, Day, etc.  It's useful for building
timestamps that are independent of LabVIEW's timestamp functions. 
Note, however, no attempt is made to accommodate DST shifts!
It has a fundamental problem too. Your "Error
correction" is not right. You adjust in fact for your local timezone
since the LabVIEW timestamp is defined to be in relation to Midnight on
January 1, 1904 Universal Time, or abbreviated UTC. Without your "Error
Correction" you get the actual date and time in UTC.

Your function gives for my current location and time July 6, 2006,
23:52.17 while I have July 7, 2006, 9:52.17 and that is at UTC + 2
hours. Basically you seem to have programmed this VI in UTC -8 which I
guess is Pacific Time, No Daylight Saving Time.

As you can see time in computer programs can be a complicated matter! ;-)

Rolf Kalbermatter

[tbd]

> It has a fundamental problem too. Your "Error correction" is not right.
> You adjust in fact for your local timezone since the LabVIEW timestamp is defined
> to be in relation to Midnight on January 1, 1904 Universal Time, or abbreviated UTC.
> Without your "Error Correction" you get the actual date and time in UTC.
Awsome, Rolfk - sincere thanks for this observation. :smileyhappy:
 
The, uh, "Error Correction" is now a configurabe GMT-offset so it'll work anywhere, ...anytime.  :smileywink:
Of course, its purpose is to ignore DST - to avoid having timestamps that suddenly jump forward or backward by an hour.
 


Util.Time.LabVIEWToYYMMDDhhmmss.ms.vi:
http://forums.ni.com/attachments/ni/170/194230/1/Util.Time.LabVIEWToYYMMDDhhmmss.ms.vi