Could you please attach an example that demonstrates the issue?
I am still unable to see your problem. I ran your VI and everything seems fine to me. Not sure what you want me to look for. Switching between the different UTC times, it would just adjust to the local times - 4:00am, 5:00am, 6:00am.
Could you please clarify what I should be looking for?
I apologize for the confusion. I intended to show that I could not display the correct time (in UTC) for data acquired in the UTC time interval March 11, 2007 02:00 through 02:59. LabVIEW seems determined only to display local times. The problem is that I don't want to display local time. I want to display UTC time.
In my example, the three switch positions should produce graphs with the left most label on the x-axis of March 11, 2007 01:00 UTC, March 11, 2007 02:00 UTC, and March 11, 2007 03:00 UTC respectively. (The UTC seconds I use for the Xmin are 3600 second apart.) What I see is March 11, 2007 01:00 UTC, March 11, 2007 03:00 UTC, and March 11, 2007 04:00 UTC respectively. This is incorrect.
As you pointed out, the graph shows local times. I cannot force it to display March 11,2007 02:00, a perfectly valid UTC time but invalid local time.
Anything I can do to change this?
(i think) what Greg wanted you to see was: when LabVIEW displays date-strings, it automatically adjusts for Daylight Savings Time. On those days when DST changes, anomalies may appear in the sequence of times being displayed: displayed times jump forward from 1am to 3am at the moment DST comes into affect (and, I expect, "1am" appears twice where DST ends). Greg wants to display times that don't include the DST offset - he's calling this time "UTC time". Tonp seems to have a solution that's related to "format strings", but I don't know where "%^T" is to be used (in LV7.1) and Greg needs to format the date-strings appearing on the X-axis of a chart. Tonp?
There's an Operating-system setting that can be changed so that when LabVIEW builds a date-string, DST is ignored. I think Greg wants to design his software so that it will work as intended - without requiring an OS setting to be changed.
Message Edited by tbd on 03-27-2007 04:39 PM
Well said! Thanks for helping clarify things.
P.S. TonP, I haven't tried the format string you've suggested... but will very soon! Thanks also.
I tried your suggestion for the format string. I still have the same problem: unable to display the time interval 03/11/2007 02:00 to 02:59. Perhaps I've made a mistake implementing your suggestion.
Please forgive me for using the acronym UTC without explanation. From Wikipedia:
Coordinated Universal Time (UTC) is a high-precision atomic time standard. UTC has uniform seconds defined by International Atomic Time (TAI), with leap seconds announced at irregular intervals to compensate for the earth's slowing rotation and other discrepancies. Leap seconds allow UTC to closely track Universal Time (UT), a time standard based not on the uniform passage of seconds, but on Earth's angular rotation.
Time zones around the world are expressed as positive or negative offsets from UTC. As the zero-point reference, UTC is also referred to as Zulu time (Z). UTC is often referred to as Greenwich Mean Time when describing time zones, although strictly speaking, it is only an approximation.
It may not be obvious from this definition, but UTC does not change during daylight savings time. For those of us in the Pacific NW, our local offset from UTC changes from -8 hours during standard time to -7 hours during daylight savings time.
We use UTC to time tag our data because it is continuous, lacking any of the discontinuities that occur at daylight savings time changes. It is this continuous and unambiguous display that I want to show on the x-axis of my LabVIEW 7 graphs.