Seconds since 1970?

[rnelsonee]

In LabVIEW 6.1 and earlier, there was a "seconds since 1970" function available in Time and Dialog which returned a nice DBL that was exactly that.  With 7.1 though, it's been replaced with "Date/Time to seconds", which does nothing but output a time cluster.  Now, I can convert the cluster to a DBL, but since LabVIEW now counts seconds from 1904, the DBL is much less accurate, and pretty much worthless.

What I'm trying to do is get an I-32 number that represents seconds from 1970 (it's referred to as UTC in my documentation).  Before I could just use 6.1's "Seconds since 1970" and convert DBL to I32.  I can't do that with LabVIEW anymore, and was wondering how to do this.  As a last resort, I could try to find a simple C program and interface to that, but I'd rather keep it all-LabVIEW.

If anyone has an pointers, just let me know.  Thanks!

-- Rick

[Dennis_Knutson]

I cannot find "seconds since 1970" in 6.1. What 6.1 has is Get Date/Time in Seconds that returns a DBL seconds since 1904 and 7.1 has Get Date/time in Seconds that returns a time stamp with number of seconds since 1904. Where did this seconds from 1970 function come from? If you want an I32 seconds since 1970, use the Get Date/Time in Seconds, convert to a DBL, subtract the number of seconds between 1904 and 1970, and convert the result to I32.

[Mcdan]

rnelsonee,

I would take the current time and subtract the constant value of 12:00.000 AM 01/01/1970 from it.  Then convert this to an I32.  I've attached an example.

Hope this helps,

Dan

[rnelsonee]

Ooh, I was finally able to double-check, and you're right, it's from 1904, not 1970.  But it used to return a DBL, so when I subtraced the number of seconds between 1904 and 1970, the value would increment nicely.  I tried Dennis' solution before, but it didn't work (the DBL seems to be above the max range once it's converted), so subtracting that constant out gives me 1122650000 constantly.

I looked at the VI that was posted by Dan, and that works.  Nice and simple - I didn't know you could subtract time clusters like that.

So I guess the lesson is keep it as a time constant as long as possible before converting to your seconds (no matter if its a double, or integer, or whatever).

Thanks!

[Mcdan]

rnelsonee,

I origionally ran in to the problem that you saw.  This however was not a problem with the timestamp, but rather that the defualt significant digits displayed for a double is set to 6.  Therefore the result was rounded to 6 significant digits.  However if you right click on the indicator and go to it's format and precision and change it to display more significant digits this problem will go away, and all digits can be displayed.

Just an FYI,
Dan

[rnelsonee]

Update: OK, I got it now.  Turns out both solutions work -- I had just never converted back to I32.  If you keep it as a double, it's an unchanging number.  I keep thinking that since I32 are less 'percise' than doubles, that if the double is broken (stuck at a constant variable), then I figured the I32 would also fail to increment, so I never took that final step.  So subtracting the time cluster or the number of seconds between 1904 and 1970 both work.  Good thing I tried both - I realized the number of seconds between the two years I got from the internet was off by a little bit (and I did remember to change Dan's VI to midnight, not 1:00 AM).

[Dennis_Knutson]

With code shown in the attachment, I get the same results either way. I agree though, that subtracting the time stamps makes things simpler.

[rnelsonee]

Ah, more fun stuff.  When I put that code into my computer (the .jpg), the results are 7200 seconds off, which is 2 hours (I have to put in 1:00 AM on 1/1/1970).  I'm chalking that up to Daylight Saving Time....

Either way, I learned a lot on how to deal with these Timestamps so I should be able to verify that.  Thanks guys.

[tbob]

Dennis and Mcdan:  Why are you using 11:00:00.000 as the timestamp for 12/31/69.  Shouldn't that be 11:59:59.999?  Seems to me like you are adding another hour into the result.

[Mcdan]

Hmm... on my block diagram it shows up as 12:00:00.000 1/1/70.  I wonder if it's being adjusted for timezone/daylight savings time settings.

Dan