04-11-2012 08:52 AM
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?
Solved! Go to Solution.
04-11-2012 08:55 AM
I do realize that 916291696-916205296 = 86400s = 1day.
04-11-2012 08:56 AM - edited 04-11-2012 08:57 AM
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.
04-11-2012 08:58 AM
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.
04-11-2012 09:01 AM
Ah, I just saw that and tried to edit my post before you saw it
You should format the timestamp into something that is compatible with the Javascript parsing using the get date/time string VI.
04-11-2012 09:12 AM
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.
04-12-2012 03:47 AM
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.
04-12-2012 09:16 AM
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.
04-13-2012 07:07 AM
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>
04-13-2012 07:59 AM - edited 04-13-2012 08:04 AM
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.