LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How can I get LabVIEW 7.1 to display the UTC time 03/11/2007 0230?

Hello Greg,
 
I am pretty familiar with the UTC term, so that was not the confusing part. I just could not see how your example was demonstrating the problem you were describing. If I run your example without any modifications I see 4:00 am, 5:00am, 6:00am on 3/11/2007 that correspond to to 0100, 0200, and 0300 UTC. If I use Tonp's suggestion and modify the date string in Advanced editing mode in Graph Properties»Format and Precision to reflect UTC
%^<%X %x%Z>T then the time on the graph would change to 9:00am, 10:00am, and 11:00am respectively, which is correct in respect to the central time zone (-0500) (includes +1DST), but very strange at the same time that 0100 UTC = 9:00am UTC. I am attaching a picture that shows 0200 UTC as 10:00 am UTC. %Z shows the time zone.
 
I will have to do some more research to figure out the discrepancy. Suggestions are always welcome. TDB, thank you for your input as well. Greg, you can uncheck the DST option for your OS by double-clicking on your system clock and selecting the Time Zone tab. See if that changes anything.
 
Here is also a KB on how the new changes in DST will affect your software.
 
Hope we are getting closer to resolving your issue.
Best regards,
 

Message Edited by Kalin T on 03-28-2007 02:24 PM

Kalin T.
0 Kudos
Message 11 of 36
(1,848 Views)

Kalin,

Thanks for sticking with me on this.  I intended my example to show that I could not get the x-axis to display the time period March 11, 2007 02:00 through 02:59, no matter what number of seconds I used for xmin.  I apologize for not realizing that you are not in the Pacific time zone and thus would not see the same date/time on the x-axis (for the number of seconds used for xmin) as I do.

I've attached some screen shots of the program executing on my computer.  You can see that even though I change xmin by 3600 seconds to move from 0100 to 0200, the x-axis label changes by 7200 seconds to 0300.  No matter what numer I use for xmin, I cannot display 03/11/2007 0200.

I'm still not sure that I fully understand your answer.  Can you display a graph with March 11, 2007 0200 as xmin?  I cannot unless... I follow your suggestion and disable Windows' observance of daylight savings time.  (Thank you for the idea.)  That works.

Unfortunately, I'm supporting this application for other people's use within our company.  I don't have the option of disabling Windows observance of daylight savings time on the client's computer.

I would appreciate it if NI would consider making it possible for charts, graphs, and indicators to optionally ignore the operating system's daylight savings time flag.  Like most customers, I want it all.  That is, the ability to display the data using local time (with DST) or UTC (independent of what the operating system is set for).  I think you may have already implemented that functionality for the seconds to date/time function in LabVIEW 8.2

Thanks again.

    Greg

 

0 Kudos
Message 12 of 36
(1,833 Views)

Hi Greg, Kalin (,Tonp)

I'm glad Greg posed this question - DST-independent time-strings can be important.  Thanks to Tonp for the charting-solution (and thanks to Kalin for clarifying Tonp's solution - Smiley Wink - )  Attached is a pic of Kalin's description for forcing X-axis time to show "UTC".

For purposes of creating a "UTC-normalized" timestamp for text-data-records, I'd be interested in how to get the "Format Date/Time String" or another date-string function to build these UTC times(?)

Cheers!

Message Edited by tbd on 03-28-2007 04:51 PM

"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
0 Kudos
Message 13 of 36
(1,827 Views)

Kalin, tbd & TonP,

Thanks for your help and patience.  I finally get it.

By removing the %Z from the format string you suggested, I get exactly what I need.  UTC time.

Thank you, thank you, thank you.

       Greg

 

P.S.  tbd, Thanks for sending the picture of the dialog box (with the advanced options radio button selected).  I had set aside this task, thinking I couldn't do what I wanted to do.  I tried the format string you suggested immediately after seeing your post.  And it works!  Thanks.

TonP, thanks for heading us in the right direction!

 

0 Kudos
Message 14 of 36
(1,817 Views)

Kalin, tbd, and TonP,

This is embarassing.  The only reason the format string worked is that I hadn't reset Windows to respect DST.  When I reset Windows to respect DST,  I got the same no 0200 hour behavior.  Rats.

I give up!  I feel like I'm wasting too much of your time.

Thanks for trying to help.

    Greg

0 Kudos
Message 15 of 36
(1,818 Views)

Hey Greg, Kalin,

      Attached is a LV7.1 VI that plots three points on a chart where t-zero is 1:30 am, March 11, 2007,  and delta-x is 3600 seconds.  I've tried using %<%X %x>T and %^<%X %x>T - and see the 2-hour-jump both ways. Smiley Surprised

Kalin, do you see the 2-hour-jump when you run this VI?  Is "absolute time" (in the description for the %T format-specifier) supposed to mean "UTC" time?

Thanks, Cheers!

Message Edited by tbd on 03-28-2007 08:55 PM

"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
0 Kudos
Message 16 of 36
(1,823 Views)
If your formatter starts with %^ then it shows UTC (you can see this by including the time zone (%Z)), if it starts with %(....)T then it will show the time in local time zone. It would be wonderfull to set the timezone of a specific control! (i have the feeling you can I just don't know how)

Absolute time does means UTC, but the standard display (%(...)T) is in local time


Ton

Message Edited by TonP on 04-12-2007 01:18 AM

Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
0 Kudos
Message 17 of 36
(1,769 Views)
I wonder if this will do it?
I know that the scales in a graph will not follow the locale decimal separator in 7.1, but it does in 8.2. There might be other issues formatting the date on the scale of a graph.
This uses a windows dll to get the local time zone offset (not pretty!). This time and date stuff gets really complicated with other applications like Excel.
0 Kudos
Message 18 of 36
(1,759 Views)

Hi TonP,

     I think the %^ formatter doesn't address the original problem!Smiley Surprised  Greg's point is: when displaying DST-adjusted times, gaps (or "compressions") occur in time-string sequences at the moment DST status changes.  Greg wanted to display a time-sequence without any DST offset - but he doesn't want to have to change an OS setting!  Can you modify my example so there's no gap?

Hi Odd_Modem,

>This time and date stuff gets really complicated with other applications like Excel...

I haven't done much with Excel, but it seems messy enough in LabVIEW (to anyone who cares about contiguous time-stamping!)  To avoid the mess, I'm logging UTC time - and waiting for somebody to complain that the times are (currently) off by an hour.Smiley Wink

We could also keep a DST-stripping-solution all-G! (not that i've actually tested this! Smiley Tongue -)

 

Message Edited by tbd on 04-14-2007 01:16 AM

"Inside every large program is a small program struggling to get out." (attributed to Tony Hoare)
0 Kudos
Message 19 of 36
(1,744 Views)
TBD,

the issue was (as I understood) that Greg couldn't display an UTC time.
The display used local time instead of UTC LabVIEW internally uses UTC and not local time, for display purposes it CAN be converted into local time.

See the following screenshot:

where I put local time in (CET =UTC+2 currently) and output is as UTC, the 'West-Europa (zomertijd)' means LV gets the name of the timezone from the OS (dutch winXP)

Maybe I don't get the problem, but I have the feeling that Greg just set it's computer to London time which uses DST?

Ton
Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
0 Kudos
Message 20 of 36
(1,732 Views)