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

[rolfk]

---

@TonP wrote:
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

---

I think the problem is as follows: LabVIEW internally uses UTC to store the seconds but when displaying them always converts them to local time. You can of course adjust for this by subtracting the (calculated) timezone offset from a timestamp and that will display the timestamp as UTC but it will still use local time format and the OS functions to format for that and technically the timestamp Greg would like to see does not exist in local time format so can't really be formatted by the OS functions for local time format.
Now in LabVIEW since 8.0 they added the possibility to display UTC time but I'm not sure they are doing that by using OS fucntions that format UTC strings (not even sure they exist on all platforms) or by just calculating the timezone offset and adjusting the timestamp for that before converting it in a string (This has a high chance actually since it will behave the same on all platforms independant if they support UTC time formatting or not). Unless the conversion routine is explicitedly aware that it needs to to UTC time formatting it will always generate a timegap or timeoverlap when DST changes even if you try to trick it into doing UTC by adjusting the timestamp beforehand.

Rolf Kalbermatter

Message Edited by rolfk on 04-14-2007 01:08 PM

[tst]

---

@tbd wrote:

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

---

I haven't followed the thread at all, and I'm not sure entirely what the code does, but I just wanted to point out that had you tested the VI, you would have found out that it will fail for the year 2400.

Years divisible by 400 (1600, 2000, 2400, etc.) are not leap years.

[rolfk]

---

@tst wrote:

I haven't followed the thread at all, and I'm not sure entirely what the code does, but I just wanted to point out that had you tested the VI, you would have found out that it will fail for the year 2400.

Years divisible by 400 (1600, 2000, 2400, etc.) are not leap years.

---

And then there is the exeption to the exception that says that every 2000 years or so that exception does not apply. Just check in your calender for February 29, 2000

Rolf Kalbermatter

[tbd]

Hi TonP!

---

the issue was (as I understood) that Greg couldn't display an UTC time.

---

I agree! - but I don't think "^%" always displays "UTC" time!   During Daylight Savings Time (in places where it's used) "%^" displays UTC+1 - and that causes the phenomenon: "I cannot display the UTC times that would not be found in local time" (because Greg is in a DST zone).

UTC should allow everyone to agree on what single time it is.  By calling "%^" UTC it could create arguments like

> "I'm UTC"!

< No, I'm UTC

> Nooooo, I'M UTC

< No, you think you're UTC, but you're really UTC+1

> ... I think were both UTC!

< er, we're two different times, how can we both be UTC?

.

.

.

< I'm gonna have a beer

> I'm gonna have a lobotomy

< perhaps I'll join you...

[tbd]

Hi test,

      Well the code doesn't have to work in 2400 - just between 1904 and (roughly) 2040 - when all LabVIEW's date functions stop working.

I highly suspect that NI choose to base their dates at 1904 because 1900 isn't a leap-year - making the seconds-to-date-calcs somewhat simpler.

hmmm, div by 4 unless div by 100, unless div by 400, unless div by 2000 -  

I'm so confused - is a year-2000-check neede to fix it?

Message Edited by tbd on 04-15-2007 12:21 AM

[tbd]

---

@rolfk wrote:

---

@tst wrote:

I haven't followed the thread at all, and I'm not sure entirely what the code does, but I just wanted to point out that had you tested the VI, you would have found out that it will fail for the year 2400.

Years divisible by 400 (1600, 2000, 2400, etc.) are not leap years.

---

And then there is the exeption to the exception that says that every 2000 years or so that exception does not apply. Just check in your calender for February 29, 2000
Rolf Kalbermatter

---

Hi Rolf,

      Your right, and I think tst is wrong! (amazing and unusual as it may be.)  Years divisible by 400 ARE leap-years (unless they fall under the 2000 year exception.)  So 1600 and 2400 will be (maybe I better mark 2400 in my calendar, so I don't forget - )

Cheers.

[tst]

---

@tbd wrote:

I highly suspect that NI choose to base their dates at 1904 because 1900 isn't a leap-year - making the seconds-to-date-calcs somewhat simpler.

---

As far as I know, LV uses 1904 as the epoch because that's what the Mac used. Apple may have chosen it for that reason.

Microsoft used 1900, but had some sort of trick to handle feb 1900.

In any case, Rolf was not contradicting me (in the same way that I was not contradicting you). He simply added another exception.

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

[TCPlomp]

---

@tbd wrote:

but I don't think "^%" always displays "UTC" time!   During Daylight Savings Time (in places where it's used) "%^" displays UTC+1 - and that causes the phenomenon: "I cannot display the UTC times that would not be found in local time" (because Greg is in a DST zone).

---

Sorry tbd, but I can't agree with you see the following code:

Where the first array (local time) shows a leap in DST timing, and the second array shows no leap (the UTC offset stays 0!)

Ton (in 8.2.0)

Message Edited by TonP on 04-15-2007 06:23 PM

[rolfk]

---

@tst wrote:

---

@tbd wrote:

I highly suspect that NI choose to base their dates at 1904 because 1900 isn't a leap-year - making the seconds-to-date-calcs somewhat simpler.

---

As far as I know, LV uses 1904 as the epoch because that's what the Mac used. Apple may have chosen it for that reason.

Microsoft used 1900, but had some sort of trick to handle feb 1900.

In any case, Rolf was not contradicting me (in the same way that I was not contradicting you). He simply added another exception.

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

---

Well after some more thinking I believe I have to contradict you anyhow.  😉
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!
So I believe that the example you responded too will already have in 2100 a problem as it does not adjust for the 100 year non-leap year rule.

And yes the LabVIEW timestamp should allow for some whooping 1904 +- 2^63 seconds (292 billion years) so I'm not sure the universe will still exist at that point. Of course I wouldn't expect LabVIEW to know how to format a date/time stamp that occurres in 1000 years correctly in the format that is used at that time.

Rolf Kalbermatter

Message Edited by rolfk on 04-15-2007 08:02 PM

[tbd]

Hi TonP,

      It looks like you're right - under 8.2, and I'm right under 7.1.   I recently installed 8.2 and just couldn't reproduce results to contradict you - even using the example I posted just for the purpose!  Then I tried the example under 7.1 and presto! - a (chart-X-scale) leap even using "%^".

5 stars for your patience.   (now where's that beer...)

Cheers!