Jump to content
jgcode

Timestamp support for Format into String & Scan Variant From String (String Package)

Recommended Posts

This OpenG Review is now closed.

This review relates to this thread here regarding support for the Timestamp datatype in the Format to String VI (among others).

With the release of OpenG LabVIEW Data Library 4.1.0.16 it is now possible to parse Waveform and Refnum datatypes correctly (read about the original ideas here) e.g:

Waveform (Timestamp)

post-10325-0-91260800-1318134236.png

Refnum (VI Server)

post-10325-0-26772700-1318134587.png

Therefore this review deals with how to modify the Format to String VI and subsequently its complementary VI Scan Variant From String to support Timestamps.

Currently the Format To String VI is in the process of being modified to support:

U64 and I64

post-10325-0-93832200-1318134234.png

DAQ

post-10325-0-59348000-1318134223_thumb.p

Refnums

post-10325-0-09444800-1318134229_thumb.p

Waveforms (example only - to be discussed here in review)

post-10325-0-03410500-1318134239_thumb.p

Ideally we would like the same functionality mirrored in Scan Variant From String where possible:

post-10325-0-22823900-1318134233_thumb.p

However the issue is that is seems that a Timestamp which has been formatted to a string can only be scanned back using the format specifier %T and must have been formatted using the Format to String and not the Format Date/Time primitive.

But the Format Data/Time primitive is a more readable string and might be preferred i.e. to format a Timestamp to a string with no intention of converting it back.

post-10325-0-68374400-1318135373.png

Therefore the main question is: How would you prefer to see this integrated?

  • What formats should be supported?
  • Should multiple formats be supported so the user can choose which, acknowledging some will not be able to be converted back?

To aid this discussion attached is a code stub (if it helps) to get you started if you want to post code.

post-10325-0-04153800-1318135979_thumb.p

Kind Regards

Jonathon Green

OpenG Manager

Share this post


Link to post
Share on other sites

For formatting the string I would prefer the ISO8601 format.

Current timestamp 2011-10-10T17:43Z .

  • Like 1

Share this post


Link to post
Share on other sites

Current timestamp 2011-10-10T17:43Z .

I like how you posted that on a day where the month and day are degenerate. :)

  • Like 1

Share this post


Link to post
Share on other sites

After a few dark side and twitter posts cursing date and time formatting, I have to say I STRONGLY support using ISO 8601 compliant strings. Be aware that the format specifiers for the "Format Date/Time" primitive are NOT always interchangeable with ISO 8601.

I posted an ISO-8601 example on the dark side that supports extended and basic formats as well as ordinal dates.

https://decibel.ni.c...t/docs/DOC-7199

I've attached a copy here.

post-949-0-73980400-1318360473.png

8601 UTC Date-Time String.vi

  • Like 1

Share this post


Link to post
Share on other sites

I have to say I STRONGLY support using ISO 8601 compliant strings.

Just to be clear:

You want Format into String to convert a Timestamp into an ISO 8601 formatted string.

And you want to input this ISO 8601 formatted string (and only this type of formatted string) into Scan Variant From String and have it converted to a Timestamp?

Share this post


Link to post
Share on other sites

Just to be clear:

You want Format into String to convert a Timestamp into an ISO 8601 formatted string.

And you want to input this ISO 8601 formatted string (and only this type of formatted string) into Scan Variant From String and have it converted to a Timestamp?

Maybe I'm missing something, but it is possible to scan any type of timestamp format with the ScanFromString.

You just have to specify format in more detail, e.g. if I want to scan ISO format I just specify

%<%Y-%m-%dT%H:%MZ>T

/J

Edited by Mellroth

Share this post


Link to post
Share on other sites

I don't think its as easy as choosing function A or function B to create the string. The important question to answer is what do we want to use the string for?

ISO-8601 is extremely flexible about precision and units. Ton gave the classic example that might be used in recording the basic date and time of an event. He used the UTC (Coordinated Universal Time) option of 8601.

A UTC string can only be created using the Format Date/Time String function because the native Format to String function has no flag or option for UTC.

There is no Scan from Date/Time String function, so we must break down the UTC string either into a date/time record cluster (yuck) or use the Scan from String function. Just as the Format to String function, there is no accounting for TZ or DST.

The solution is to convert the string to a local time stamp, convert that to a string using the Format Date/Time String with UTC format as TRUE, then convert that to a time stamp again. Subtract the last time stamp from the previous to determine the TZ / DST relative time and then subtract to get the true time. (see attached)

I personally include the seconds portion in my UTC timestamps. This simply requires adding a %S format specifier.

This brings up a question: What precision might someone want to record a timestamp value to? A LabVIEW timestamp is accurate to 0.05421010862427522170... attoseconds.

ISO 8601 does support fractional seconds. The spec is nice enough to support a comma or period as a separator between the whole and fractional part, but this is going to be one very long string if we write the full accuracy of the time stamp into the string.

I suspect that waveform timestamp data may need to be saved differently than a simple timestamp. Maybe as a cluster of I64 and U64? It typecasts nicely and the seconds (I64) part may be sufficient for the Format Variant to String.

ISO 8601 String Tests.vi

Edited by Phillip Brooks

Share this post


Link to post
Share on other sites

OK. Instead of trying to share my bad experiences with quirks of LV time formats, I'll toss out my first example as requested.

I'm actually working from a LV2010 machine at the time too!

post-949-0-14932600-1318509335_thumb.png

Share this post


Link to post
Share on other sites

I think it has been there since 7.1

LV 7 still had some issues with DST. (here's a lengthy discussion on DST stuff).

Ton

Share this post


Link to post
Share on other sites

...

Please excuse me now while I search eBay for a slightly used tantō...

Nice signature ;-)

/J

Edited by Mellroth

Share this post


Link to post
Share on other sites

post-949-0-35223600-1318521705_thumb.png

Ok, so we have the preferred default output (given the VI supports overriding this format specifier) and this answers the original question.

Is there any other feedback for this set of VIs?

Share this post


Link to post
Share on other sites

Ok, so we have the preferred default output (given the VI supports overriding this format specifier) and this answers the original question.

Is there any other feedback for this set of VIs?

I guess not...

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.