convert 64bit UTC time since 1 jan 1601 to current time labview 7.1

[_K_]

I need to convert a 64 bit UTC time 100-nanosecond intervals since january 1, 1601 to current time. I'm running LV7.1 on WinXP. I cannot identify any calls from windows dll's. I figured there would be something in there. Any format string, or what-ever, will do. I have a file with 8 bytes that containe the time. Help!

Message Edited by _K_ on 01-25-2008 09:32 AM

[tbd]

Hi _K_,

      The conversion doesn't look too difficult, in fact, here's a start.  I really wanted to test this, but an hour of searching has netted me no example year-1600-based, U64 timestamps to test with.  Keywords seem to be "ASF" and GPS.  Perhaps you would supply a few strings - in whatever the native format is (i.e. Hex, binary) - a file would be ideal! (?)

There are two VIs, one to convert the U64 (bin-string) int to EXT, the other to convert the EXT (centi-nanoseconds since 1600) to LabVIEW seconds since Jan 1, 1901.

It wouldn't surprise me if the ToSecSince1901 VI needs tweaking, though it should be close.

... then again, tst has a habit of pointing out already "known" solutions - from here on this forum, or on OpenG - that may be better.

Cheers!

Message Edited by tbd on 01-26-2008 05:29 PM

[tbd]

... adjusted for base-year = 1601 (instead of 1600)

[_K_]

Thanks! This should get me going. It seems to work great at 30hz. I don't have any data at higher freq. to test yet. I hope this time sample is what you were wanting. Let me know if you need more.

Message Edited by _K_ on 01-26-2008 11:27 PM

[tbd]

It seems to work great at 30hz...

If it's been validated with real-time data, Excellent!  The posted-data looks about a year old and without knowing what the times were actually supposed to be, I wouldn't have "warm-fuzzys" until I'd validated one U64-to-seconds conversion against known data (scrutinizing the correctness of the conversion - year, mo, day, etc - down to the second - even milliseconds if the known data provides it.)

I expect you've already done this, but just want to make sure.  Otherwise, if it works for one U64. then it should work for all

Cheers!

[_K_]

The data is from Feb, 6 2007. There is a file reference time of "2/6/2007 12:45:25.900" in the header of the data.

This data as you know has 2/5/2007 12:45:43.***. Unfortunately I have no way to verify the time code receiver settings versus the PC time setting from the time of the recording. My immediate concern is to get the data into a form that I can get my program running. I thought there might be some adjustment needed to correct time. I still need to test at 500+hz data rate. Lots to do, but I'm getting off and running. I hope to have an opportunity soon to examine data with a known UTC time. I will post the results. You have been a great help, and I wish I had an answer for you now.

[tbd]

Hi _K_,

---

The data is from Feb, 6 2007. There is a file reference time of "2/6/2007 12:45:25.900" in the header of the data.

This data as you know has 2/5/2007 12:45:43.***.

---

This is good info. - it implied an error in the value of 110668 as representing the day-count from 1601 to (but not including) 1904, and the following math justifies a correction to 110667.  Since this number is subtracted from the input during the conversion, it should improve things.

'Dunno whether to be worried about the difference in seconds; it could be the file was written shortly after the data was collected.  Possibly, the PC's timebase differs from the data-source's timebase.  While the "seconds" part of the calc is very straight-forward, probably still need to validate it once.

Re: 500Hz data-rate, doubt this calc will slow you down, though if it comes to squeezing cpu-cycles out of a diagram, you might post this as a new thread with that as the subject.  It sounds like "we're" collecting data in a loop(?)   First questions might be: what are the external dependencies - what kind of IO is performed with what kind of hardware - and is there a [loop] timing-precision requirement?

Cheers.

Day-count calculation (days from 1601 to 1904)

days: "normal" 4 years    =   1461 (  366 +  3*365  =  1461 ) 1st year is leap-year
days: "normal" century    =  36524 ( 1460 + 24*1461 = 29220 ) 1st quad-year isn't a leap

      From first day of Start year
        |     To (but not including) first day of End year
        |      |
      Start   End
days: 1600 - 1700 =  36525 (1600 WAS a leap year, by 400 year exception)
days: 1700 - 1800 =  36524
days: 1800 - 1900 =  36524
days: 1900 - 1904 =   1460 (1900 was NOT a leap-year, by 100 year exception)
-----------------   ------
days: 1600 - 1904   111033
days: 1600 - 1601     -366 (1600 WAS a leap-year, by 400 year exception)
-----------------    -----
days: 1601 - 1904   110667