LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

parse labview timestamp xml in javascript

Solved!
Go to solution

Hi, im reading XML files created from labview7.1 with javascript and it works great, the only problem is that I dont know how to parse the timestamp. For exampel

...

<Timestamp>
<Name>Eximination Date</Name>
<Cluster>
<Name></Name>
<NumElts>4</NumElts>
<I32>
<Name></Name>
<Val>0</Val>
</I32>
<I32>
<Name></Name>
<Val>0</Val>
</I32>
<I32>
<Name></Name>
<Val>-916291696</Val>
</I32>
<I32>
<Name></Name>
<Val>0</Val>
</I32>
</Cluster>
</Timestamp>

...

should be the date 2011-01-24 and

...

<Timestamp>
<Name>Eximination Date</Name>
<Cluster>
<Name></Name>
<NumElts>4</NumElts>
<I32>
<Name></Name>
<Val>0</Val>
</I32>
<I32>
<Name></Name>
<Val>0</Val>
</I32>
<I32>
<Name></Name>
<Val>-916205296</Val>
</I32>
<I32>
<Name></Name>
<Val>0</Val>
</I32>
</Cluster>
</Timestamp>

...

is 2011-01-25. Any clues?

0 Kudos
Message 1 of 10
(4,838 Views)

I do realize that 916291696-916205296 = 86400s = 1day.

0 Kudos
Message 2 of 10
(4,836 Views)

While this strictly has nothing to do with LabVIEW, since you did generate the XML with LabVIEW, I will go ahead and point you to jquery. It is a lightweight module you can import which has lot's of neat XML and DOM traversal functions built in. Here is a tutorial on using jquery to parse XML.

=====================
LabVIEW 2012


0 Kudos
Message 3 of 10
(4,835 Views)

Hi Steve, the problem is not to parse the values from the xml, the problem is that I dont know what each of the values in the timestamp cluster (in the xml file) represents.

0 Kudos
Message 4 of 10
(4,832 Views)

Ah, I just saw that and tried to edit my post before you saw it Smiley Happy

 

You should format the timestamp into something that is compatible with the Javascript parsing using the get date/time string VI.

=====================
LabVIEW 2012


0 Kudos
Message 5 of 10
(4,829 Views)

I'm not sure if this is what you are asking, but the timestamp is the number of seconds since 12:00 a.m., Friday, January 1, 1904, Universal Time.

=====================
LabVIEW 2012


0 Kudos
Message 6 of 10
(4,824 Views)

Hmm, are you sure that "number of seconds since 12:00 a.m., Friday, January 1, 1904, Universal Time" is correct.

In my example above I got 916291696 in the timestamp cluster, one (1) year is 31556926 seconds. And 916291696/31556926 is about 29. The timestamp of 916291696 should represent the date 2011-01-24 so 916291696 seems to be the number of seconds since 1982 and not 1904.

What I want to do is to read the numeric values and calculate what date the timestamp represents.

0 Kudos
Message 7 of 10
(4,815 Views)

I am seeing the same thing you are. But the help file indicates it is since 1904 http://zone.ni.com/reference/en-XX/help/371361H-01/glang/timestamp_constant/

 

But if you place a To Double Precision Float on the timestamp it returns 3.41708E+9 for right now. Dividing by the number of seconds in a year gives 108.2. So internally it is the number of seconds since 1904 but flattening it to XML changes it somehow. That's why I say that it is best to format the timestamp to a string representation that you can convert to a Javascript timestamp. Of course if you are dealing with LabVIEW code which cannot be changed then you have to use the 1982 offset.

=====================
LabVIEW 2012


0 Kudos
Message 8 of 10
(4,809 Views)
Solution
Accepted by topic author Tudor

This seems to work

 

<html>
<script type="text/javascript">
console.log("Should be: 2011-01-24");
console.log(toDateTime(-916291696));
//02:00, Friday, January 1, 1904
function toDateTime(secs) {
	var i32max = 4294967295;
	var t = new Date(1904,0,1,02,00,00);
	if (secs<0) {
		secs = i32max + secs; 
	}
	t.setSeconds(secs);
	return t;
}
</script>
</html>

 

0 Kudos
Message 9 of 10
(4,797 Views)

Well a timestamp is really a 64bit + 64 bit number in LabVIEW but internally represented as a cluster of 4 * 32 Bit integer since the timestamp was intruduced before LabVIEW supported 64 bit integers.

 

The first i64 is the number of seconds since January 1, 1904 UTC and the second u64 is the fractional seconds resulting in a resolution of 1/2^64 =~ 54 * 10^21 or 54 zepto seconds, which might be smaller than quantum physics allows for.

 

The -916291696 is in fact the signed integer representation of the unsigned 32 bit integer 3378675600 which is the number of seconds you look for. For now this is enough but if you want to make your routine safe for after 2037 you should account for the upper signed 32 bit integer too. Java not having unsigned integers makes this a bit awkward.

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
Message 10 of 10
(4,791 Views)