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

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

Post by tbd » Mon, 28 Jan 2008 08:40:04


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


Util.Time.U64ToEXT.vi:
http://www.yqcomputer.com/


Util.Time.CnsSince1600ToSecSince1901.vi:
http://www.yqcomputer.com/
 
 
 

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

Post by tbd » Mon, 28 Jan 2008 17:10:05

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!

 
 
 

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

Post by _K_ » Mon, 28 Jan 2008 23:40:04

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.
 
 
 

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

Post by tbd » Tue, 29 Jan 2008 07:10:04

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. :smileywink:
'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-yeardays: "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   Enddays: 1600 - 1700 =  36525 (1600 WAS a leap year, by 400 year exception)days: 1700 - 1800 =  36524days: 1800 - 1900 =  36524days: 1900 - 1904 =   1460 (1900 was NOT a leap-year, by 100 year exception)-----------------   ------days: 1600 - 1904   111033days: 1600 - 1601     -366 (1600 WAS a leap-year, by 400 year exception)-----------------    -----days: 1601 - 1904   110667
 


Util.Time.CnsSince1601ToSecSince1901A.vi:
http://www.yqcomputer.com/