16 replies to this topic

[jgcode]

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)


Refnum (VI Server)


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



DAQ



Refnums



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




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



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.



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.








Kind Regards

Jonathon Green
OpenG Manager

[jgcode]

Admin Edit: To keep this review on topic some posts were moved to Need LVOOP Object VIs in lvdata library thread.

[Ton Plomp]

For formatting the string I would prefer the ISO8601 format.
Current timestamp 2011-10-10T17:43Z .

[Darin]

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

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

[Phillip Brooks]

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.



 8601 UTC Date-Time String.vi   28.29K   107 downloads

[jgcode]

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?

[Mellroth]

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, 12 October 2011 - 05:43 AM.

[Phillip Brooks]

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   10.03K   92 downloads

Edited by Phillip Brooks, 12 October 2011 - 06:36 PM.

[Phillip Brooks]

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!

[Mellroth]

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!

The scan from string does support UTC by specifying a ^ in the format string
If I use

%^<%Y-%m-%dT%H:%M:%S%3uZ>T if UTC
or
%<%Y-%m-%dT%H:%M:%S%3uZ>T if not UTC

in your example I think it works as expected.

/J

[Phillip Brooks]

That has got to be among the most subtle settings I've (n)ever seen!

I thought it might be new, but it was there in LV 8.6 as well! I am very dissapointed in myself for missing that

So, we can use the native Format into String and Scan from String functions with a single format specifier string to create and convert a timestamp to an ISO-8601 UTC compliant string.



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

Edited by Phillip Brooks, 13 October 2011 - 04:22 PM.

[Ton Plomp]

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

[Mellroth]

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

Nice signature ;-)

/J

Edited by Mellroth, 13 October 2011 - 07:43 PM.

[Phillip Brooks]

Nice signature ;-)

/J

I was thinking of getting a tattoo of this on my hand so I won't ever forget it...

[Phillip Brooks]

UTC in the news... http://www.popsci.co...light-neutrinos

[jgcode]

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?

[Phillip Brooks]

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...