I am trying to retrieve a date from an external XML file. My XML file looks like this:
<?xml version='1.0' standalone='yes' ?>
I can get the system to retrieve the correct XML element which shows the nested <Name> and <Cluster> elements, but I have no way of correctly extracting the date. It seems as if it is interpreting my date as seconds since 1904. I am trying to keep the XML "readable" for the end user, so it is important that this date remain in the standard US date format. I am ultimately using this date to calculate the age of something. I have code working to subtract a timestamp in date format from the current timestamp, but I can't access it when I retrieve it from XML.
From the XML schema it looks like the timestamp element requires a cluster... but there is no documentation on what to pass it. Any ideas how to retrieve a date from XML in this format in a simple and clean manner?
Here is my current VI:
Solved! Go to Solution.
Your figure cannot be seen. Please attach it to a reply so it can be hosted on the NI servers.
Where does the XML come from?
<?xml version='1.0' standalone='yes' ?>
I am trying to keep the XML "readable" for the end user, so it is important that this date remain in the standard US date format.
Sorry, but the US date format is not readable.
To get the date use a scan from string on the string inside the Cluster element with the following formatter:
with a timestamp dataformat.
The timstamp written in the Cluster element is not XML compliant.
That simply won't work. The Flatten/Unflatten XML functions in LabVIEW use a very specific XML schema. This is documented in the LabVIEW Help. That's why I asked the question as to where the XML came from. It couldn't have come from a Flatten XML function because putting in a timestamp into Flatten XML gives you this:
which you can see looks nothing like your XML. You have to use your own parsing for the date, and Ton's suggestion is the proper way to parse your date.
Ok, I solved it!
I now pass the date of birth to the parser as a string instead of the timestamp. The LabView timestamp element in their XML schema only allows for the date to be added as the number of seconds since 1904. Now I can keep the XML readable and, after parsing the string, evaluate the timestamp to determine the age.
Thanks again for your help!
Quick tip about "Bundle by Name". You don't need to bundle in all those constants where the values match what is in the cluster constant at the top. The cluster constant defines the data structure and the starting values. You only have to bundle in the values for the particular elements you want to change.
Ton's example would be a bit cleaner. Although the format string should use a capital T.
As always with dealing with time, complications could arise because of leap years and dealing with time zones. Time zones shouldn't matter for calculating years since you are rounding to years. Although you probably want to round down rather than round to nearest. (I forgot that part in my example). The problem with leap years is when you would be just within some number of days of the birthday, it would round the age up. The number of days rounded would depend on how many leap days that person has seen during their life.
One little addition to Raven's Fan (Good) example, you could skip the to timestamp conversion by making the the default value of the scan from string a timestamp.
Old thread: but still this issue is present in LV 2019. The issue is LabVIEW XML schema is unique, further when you look at how LabVIEW XML casts a timestamp is resolves as a 'cluster' of n elements of the date similar to the LabVIEW Date time rec function.
So when you drop a timestamp in a LV cluster with other labVIEW controls - you get a cluster-in-a-cluster. LabVIEW cannot even unparse a timestamp when it's in the context of a cluster of other datatypes.
Why would you do this? I have a cluster of setting to save and would include the date & time such as a calibration result cluster.
Of course NI can't fix this without breaking all previous code. But it pays to think 2x when releasing product software. I am still tripping of this to this day.