Timestamp Scan From String misbehaves, part 1

[Sci-Vi]

Not sure this has been reported before, but it certainly is a bug... It looks like if, when Scan From String is configured to read timestamps with fractional seconds but only find integer seconds format, it takes any following number it can find and adds it as full seconds to the previous scan it got ?! Certainly wrong !

LabVIEW 2011 SP1

Can someone at NI provide a CAR # for this ?

Vincent

[PhillipBrooks]

This is undesirable behavior, but I don't know if I would technically call it a bug.

Your format string tells the parser to find a fractional part that does not exist in your third string.

If the string is 00:00:30.0 then it should parse correctly. The content of the strings is inconsistent, which is a problem with the source of the data.

As a side note, there is a 4 year old CAR regarding LabVIEW not properly supporting the localization code for the decimal separator ( comma vs period )

http://forums.ni.com/t5/LabVIEW/Can-t-change-decimal-sign-in-timestamp-BUG/m-p/647863

[GeorgJ]

Hello Sci-Vi!

The behavior of the function is correct in this case. %u in the time format specifier handles both the digits before the decimal point as well as the ones after. In the example 00:00:30 15.2°C using %S%u means the function first finds 30 and additionally 15.2. Since both are the values for the seconds in the timestamp they are added together.

The correct format specifier is %<%H:%M:%u>t which returns the correct value for all the examples in your post.

Regards,

  Georg

[GerdW]

Hello Georg,

"%u in the time format specifier handles both the digits before the decimal point as well as the ones after."

Could you please check the context help for the Time Format Codes? There it only says "fractional seconds" for %u...

When using %u to convert a timestamp to string it also only outputs ".123" with no leading numbers for the fractional seconds part.

So either %u is not handled consistently within ScanFromString and FormatIntoString (in my opinion) or the LabVIEW help is wrong (or doesn't explain all the needed details)!

Could you please clarify the facts?

Edit: I agree on the solution "the data source outputs non-consistant strings" by Phillip.

[Sci-Vi]

I indeed also noticed the localization problem for timestamp scans from string, though not knowing there's been a CAR for so long about that...

Now I only partly agree with your comment. Yes you're right, the format string precisely describes a very specific format, and the input string generating the problem can be considered as not strictly corresponding to that format description (no fractional part). However, in this case I would expect:

- an error to be generated (it is not the case here), just like when any other scan from string meets an unexpected format

- at least the next number to be considered as the fractional part of seconds, not as full seconds to be added to the previously scanned number

Note that the error handling of timestamp scans is lacking in much more general cases, as I have noted in another related post.

Now, if you want to see a bug on which I hope everyone should agree, we can just make it a bit more straightforward : just use the %t format...

Now it's more difficult to find a good reason why LabVIEW is doing this ! Not even needed to mention that, when trying to successively scan both timestamp and temperature from the 3rd input string, you'll get an error for the temperature as only the "°C" is left after the timestamp conversion . Now this is ready for a CAR, don't you think ?

Regards,

Vincent

[Sci-Vi]

Sorry Georg and Gerd, did not read your answers before posting. Thank you anyway Georg for the workaround, although I agree with Gerd: I'm not sure the use of %u really is self-consistant all the way through timestamps formats, and I wouldn't be surprised if you'd find some confusion about that even within people at NI. This could then also be related to the localization separator not being properly handled... Are there accurate specifications for what behavior is actually expected from LabVIEW in the first place ? This is not the feeling we get as users, at least...

Still the last example holds and is less arguable I think...

Vincent

[GeorgJ]

Hello Gerd,

I understand that the LabVIEW help is confusing regarding %u in timestamp specifiers.

However, I cannot reproduce the behavior you describe: "When using %u to convert a timestamp to string it also only outputs ".123" with no leading numbers for the fractional seconds part."

See my output below: (I am using a German OS, so the decimal separator is a comma)

Regards,

  Georg

[GerdW]

Hi Georg,

when converting from timestamp to string you get a string with no leading numbers before the decimal separator (just fractional seconds as the context help says):

Why should %u behave different when converting from string to timestamp???

Why doesn't the context help explain the correct behaviour???

[Sci-Vi]

Hello Georg,

As I understood he was rather referring to the opposite conversion (timestamp to string, with Format Into String) :

so I would agree with him that using only %u for both integer and fractional seconds is probably not the way to go... On the other hand %<%H:%M:%S%3u>t produces the expected result (00:00:30.123).

In short the way %u should be used is not thesame for Scan From String and Format Into String...

Vincent

[Sci-Vi]

Again posting too slowly 🙂

Anyway, now we are discussing misleading documentation, but still the behavior from 5th post above is not related to %u and very much looks like a bug... Could we at least agree on that and produce a CAR for it (hopefully not for the next 4 years 🙂 ) ?

Regards,

Vincent