LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to retrieve a date in timestamp format from an XML file

Solved!
Go to solution

That's because a timestamp in LabVIEW is in fact this C definition:

 

typedef struct
{
    int64 seconds;
    uInt64 fractionalSeconds;
} Time64Rec;

 

But at the time the timestamp was introduced in LabVIEW, various C compilers still had only partial support for 64 bit integers, so the real definition was:

 

typedef struct
{
#if BigEndian
    int32 secondsHi;
    int32 secondsLo; 
    int32 fractionalSecondsHi 
    int32 fractionalSecondsLo;
#else
    int32 secondsLo;
    int32 secondsHi; 
    int32 fractionalSecondsLo; 
    int32 fractionalSecondsHi;
#endif
} Time64Rec;

 

Unfortunately rather than adding this as a datatype of its own in the LabVIEW datatype system, it was bundled together with other complex datatypes, which belong to the Waveform datatypes. It would have been more logical to give it its own distinctive datatype code such as 0x28 for instance.

And the flattened format is in fact defined as the BigEndian version of above cluster of 4 * int32 values, which for binary values would be fine.

 

But conversion to and from text form of a timestamp is an entire can of worms of its own. There are standardized formats nowadays such as ISO 8601, but they are not everywhere used and where even less so back in the old days when LabVIEW added these functions, so the chance that if you choose one that you are getting it wrong for more than 50% of the users is basically very big.

The official XML date format is in principle leaning on the ISO 8601 standard so it would have been probably a rather useful choice here. For JSON things would be different however. JSON does not know a date/time type and therefore does not specify a format for it. Java and Java Script does use the default format of the Java Date object, and that is ISO 8601 so it is common to see that in JSON, however there are just about any possible format for Date and Times in JSON (and in fact there are many XML formats that use different date/time format as the OPs example shows. Local US format is NOT a valid XML date format either!)

Rolf Kalbermatter
My Blog
0 Kudos
Message 11 of 13
(303 Views)

Rolf,

Thanks for your always thorough background. And reminding us of LabVIEW Watcom C origins on the Apple computer. I wish NI developers would have done more future-proof considerations when implementing the LabVIEW XML casting function.

 

My solution for LabVIEW XML clusters and Timestamps - is to use the String datatype in the cluster over the Timestamp record.

 

Regards

Jack

0 Kudos
Message 12 of 13
(292 Views)

Litttle nitpick: On Macintosh the Apple Macintosk Programmer Workshop was used to compile LabVIEW. Watcom C was used to compile the Windows 3.1 DOS protected mode version since Watcom provided an integrated linear 32-bit memory model even with Windows itself being 16 bit protected mode. For the true 32-bit version of Windows such as Windows NT and 95/98 LabVIEW was using Visual C 6.0. While this knew 64 bit integer datatypes internally, support for it was flaky and buggy. Many operators were either not implemented or buggy when applied to 64 bit integers. Only visual C 2005 had fully working 64 bit integer support and was also the first version to support 64-bit compilation out of the box. In Visual C 6, even things like 64-bit integer multiplication required actually to use inline assembly or external assembly object modules to avoid the bugs in the MSVC compiler. The alternative was to calculate in 32 bit space and handle carry over or borrow manually.

Rolf Kalbermatter
My Blog
0 Kudos
Message 13 of 13
(285 Views)