03-28-2007 02:16 PM - edited 03-28-2007 02:16 PM
Message Edited by Kalin T on 03-28-2007 02:24 PM
03-28-2007 03:30 PM
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
03-28-2007 04:43 PM - edited 03-28-2007 04:43 PM
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 - - ) 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
03-28-2007 07:22 PM
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!
03-28-2007 07:29 PM
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
03-28-2007 08:50 PM - edited 03-28-2007 08:50 PM
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.
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
04-11-2007 06:16 PM - edited 04-11-2007 06:16 PM
Message Edited by TonP on 04-12-2007 01:18 AM
04-11-2007 07:59 PM
04-14-2007 01:09 AM - edited 04-14-2007 01:09 AM
Hi TonP,
I think the %^ formatter doesn't address the original problem! 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.
We could also keep a DST-stripping-solution all-G! (not that i've actually tested this! -)
Message Edited by tbd on 04-14-2007 01:16 AM
04-14-2007 04:43 AM