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

[tst]

---

@rolfk wrote:

The rule as I have learned it is that every 4 years is a leap year unless it is a 100 year interval but this is again not true for 400 year intervals.  So every 400 year there is a leap year contrary to what you say. The 2000 year interval I mentioned does not really exist, that was my fault!

---

Ah. Well, I'll try to remember that come 2100.

Of course, a much easier solution (although more processor intensive) is to run a while loop where you start by assigning 31 to the day of the month element of the date\time cluster and then decrease until the month in the resulting cluster is equal to your current month. At most this loop should run 4 times for each check.

[GregO]

tbd and TonP,

You guys are great.  I apologize for not clearly communicating the problem I'm having with LabVIEW 7.1

First I want to confirm that tbd correctly understood the problem.  I can't display gapless UTC time in indicators and on the x-axis of plots.  (I can't display the "missing hour" in spring, no matter what I use for an x-axis offset, unless I change the OS settings to ignore DST.)  I'll also confirm that the ^% specifier in the time format string that TonP recommended has no effect in LabVIEW 7.1.

If I understand your most recent posts, LabVIEW 8.2 does display gapless UTC times regardless of the local time zone and OS settings.  That's just what I'm looking for.  tbd, did you confirm that LabVIEW 8.2 handles the x-axis scaling appropriately (for UTC times)?  If so, it sounds like it's time for an upgrade.

Thanks again.  I think I owe you both a beer.

     Greg

[tbd]

---

@GREGO wrote:

... tbd, did you confirm that LabVIEW 8.2 handles the x-axis scaling appropriately (for UTC times)?

---

Arrrrrrruuup! (excUuuuse me! :^P)

Yup - 8.2 chart looks good - but it took an hour to be confident; it's SO easy to screw-up here, and it seems LabVIEW isn't very friendly when it comes to displaying dates on the X-axis.  I suspect the routine that decides whether there's enough room to label ticks could use some work (it leaves big gaps under points where you'd expect a tick & label).  Also, everything has to be formatted Absolute-UTC and one has to remember to target a leap threshold time for t0 (like 1am 3/11/2007.)  Must be 20 times ! looked for the leap between 1am and 3am on Jan 1, 1904!

Thanks for the nice beer thought... (stars work too ;^) )

Cheers!

[tbd]

---

@tst wrote:

Also, if I understand correctly, LV functions should work properly for 8.x even after 2040. Don't they?

---

Hi tst,

      You made a good point before - the routine can't be used for arbitrary "date-math", but good timestamps through 2099 are probably sufficient.

Here's a curiosity for you, in LV8.2, 1/19/2038 is the max-date for the "t-zero" value in a waveform - though a simple date control allows 1600-3001.

Re: your simple DST-compensator (other post) - to be honest, I'm not really undestanding. 

Cheers!

[tst]

---

@tbd wrote:

Here's a curiosity for you, in LV8.2, 1/19/2038 is the max-date for the "t-zero" value in a waveform - though a simple date control allows 1600-3001.

---

The waveform datatype probably uses its own code. I never used it, so I don't know.

---

Re: your simple DST-compensator (other post) - to be honest, I'm not really undestanding. 

---

It's not a DST compensator, but a leap year compensator which should detect the correct amount of days in the month (assuming LV works properly).

Something like this:

[rolfk]

---

@tst wrote:

---

@tbd wrote:

Here's a curiosity for you, in LV8.2, 1/19/2038 is the max-date for the "t-zero" value in a waveform - though a simple date control allows 1600-3001.

---

The waveform datatype probably uses its own code. I never used it, so I don't know.

---

It's probably just that nobody has come around yet to change the t0 property inside the waveform to be a timestamp datatype instead of an unsigned 32bit integer which was the default for times in LabVIEW 3. Or they use a double precision but use somewhere along the lines for formatting a function that coerces to unsigned int anyhow.

If it is only a coercion inside a function for formatting timestamp strings the change would seem easy to me but if it is the datatype inside the data structure for a graph a change always also involves adding mutation code for translation for VIs created in older versions of LabVIEW and a lot of testing.

Rolf Kalbermatter