Scan From String - Timestamp format - bug and workaround

[DavidBoyd]

I never noticed this behavior before.  To me it seems like a subtle bug in Scan From String's functionality with %T (timestamp) scanning.  Other format specifiers tolerate leading whitespace in the input string, but not %T?  The demo VI is attached.

Tested on LV 2019 SP1 but I'd be happy to have any confirmation of whether this issue persists in later releases.

Note that I rendered the format and input strings with backslash display mode and colored the extra whitespace characters to make it more eye-evident what I'm demonstrating.  Of  course, the converted timestamps will show in your target timezone since I'm not including timezone info in the string-to-TS conversions here.

Dave

[Jay14159265]

From labview 2020

[DavidBoyd]

Thanks, that's interesting.  So, LV2020 throws an error on the additional whitespace case?  Still not ideal, but different.

[Jay14159265]

---

@DavidBoyd wrote:

Thanks, that's interesting.  So, LV2020 throws an error on the additional whitespace case?  Still not ideal, but different.

---

Not sure if you can use it in your case but trim whitespace works great for this kind of thing. 

[billko]

This is interesting.  Maybe I wasn't hallucinating when I saw behavior change in the scan from string from somewhere between LV 2012 and LV 2015.  Same thing, kind of.  In this case, it was how it handled white space before a number.

[altenbach]

I agree that LabVIEW could be a bit more forgiving, but the %Y is assumed to be exactly four digits and that information is probably used to speed up the parsing. Seems we won't have further problems until after the year 9999 😄 (The "Y10k problem"!, fortunately we have time to prepare... )

(Yes, I would also use trim whitespace if this is a problem)

[JÞB]

Remove the time container, %<>T you really are looking to parse time element formats part by part then you assume the string is in local time when it contains no zone information.  That is a little developer error to assume your sting has meaning that it does not contain.

So, converting a string like you have done means you can't use the undeclared whitespace within a time container and the regex fails.  However, the whitespace will be ignored by %Y ...... without the container and an Appopriate value will be returned.  

Of course, that "T" you are ignoring may very well indicate Tango Timezone or, GMT-7 hrs

[pincpanter]

---

@JÞB  ha scritto:

Of course, that "T" you are ignoring may very well indicate Tango Timezone or, GMT-7 hrs

---

The "T" means that the input string is a date in ISO 8601 format.

[JÞB]

---

@pincpanter wrote:

---

@JÞB  ha scritto:

Of course, that "T" you are ignoring may very well indicate Tango Timezone or, GMT-7 hrs

---

The "T" means that the input string is a date in ISO 8601 format.

---

Aha! Yes that explains the format. Thank you. 

And is further argument to remove the Time Container.   %<>T and %^<>T only are recognized by moat programming Languages.   Each of those trace back through UTC1 and UTC to celestial observations in Greenwich without tracking the leap seconds ISO 8601 supports.

Arguments have been made to introduce a new time container type based exclusively off the SI second (%#<>T) but no agreement with civil time would be possible as each sovereign body would need to cede such law making power to a superior authority.  ISO 8601 does attempt to help out but, even then, co-ordination to your OS time becomes problematic since localized time is still leap second agnostic and you never know how many SI seconds will pass in the next decade.

[DavidBoyd]

Chris (and Jay),

Agreed on the use of Trim Whitespace.vi as a viable solution, though placing a bit of whitespace in the lead of the format string seems to work as well.

Perhaps lost in my initial post was to point up that %T, overall, with or without the specific element variations, is fundamentally NOT like the other specifiers, %f, %g, %s, etc.  All the others will happily skip past any whitespace chars in the input stream until they find something to convert, and that is well-defined behavior.  %T doesn't, and what's worse, at least for 2019 SP1 (likely other releases), it may return an incorrect conversion WITHOUT flagging an error.

I appreciate the lively discussion that sprang up around this post.  Using %<>T with embedded format specifiers is still my preferred way to parse what, in this case, is well-formatted output from an instrument.  It was only accidentally that I discovered the problem with whitespace  (not within, but solely ahead of, the text to be converted).

Best regards to all,

Dave