Message Edited by Kalin T on 03-28-2007 02:24 PM
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
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(?)
Message Edited by tbd on 03-28-2007 04:51 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.
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!
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.
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?
Message Edited by tbd on 03-28-2007 08:55 PM
Message Edited by TonP on 04-12-2007 01:18 AM
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?
>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