LabVIEW
Unusual String to Timestamp conversion behaviour?
I want to be able to convert a string representation of a Date, Date Time, Time or Time Date string to an actual Timestamp and have been playing around with possibilities. I came across what I think is a bit of strange behaviour.
Take the scenario when the string passed in could consist of a time and date or just a time: HH:MM:SS.fff dd/mm/yyyy or HH:MM:SS. Using the "Scan from String" function:
If String has the following values:
"13:25:34.678 21/06/2010" it works, the timestamp is correct
"13:25:34.678#" (# in the string is a SPACE character not an actual #!) it works, the timestamp has the correct time and a default date, 01/01/1904. Note it must be a SPACE, any other character causes an error.
"13:25:34.678" (no trailing space) it fails with an error.
If I do it the other way around, that is date first then time with the format string "%<%x %X%3u> it works in any combination of DATE TIME, DATE#, or DATE. I.e. the date on its own does not require a trailing space.
Hope that all makes sense. I wonder what's the strange behaviour: that time fails or date works!
I've attached the VI I used as well. It's the first time I've done that so I hope it works! In any case, it is as simple as the embedded image.
Would you mind to "save for previous (2020 or lower). Also make sure to include diagram constants with your various test inputs.
@andrewDJ wrote:
"13:25:34.678#" (# in the string is a SPACE character not an actual #!) it works, the timestamp has the correct time and a default date, 01/01/1904. Note it must be a SPACE, any other character causes an error.
"13:25:34.678" (no trailing space) it fails with an error.
Well, your format has a <space> at that location, so if it sees something else, there is an error of course. If you place an underline instead (both in the format and string), things work equally well.
It seems like a bad idea to define an exact format and expect it to work correctly with truncated string inputs.
Thanks. While I cannot explain the difference, it seems very fragile to even expect things to work if the input is truncated!
As a "bandaid fix", you could just blindly append a space before scanning so it works with all three of your inputs. Still feels like a kludge.
@andrewDJ wrote:
If I put an _ in the format I can use an _ or a space in the string and it works as you say. It was more the behaviour of needing a character at the end for Time only strings but not date only strings.
I actually wasn't expecting it to work if I'm honest, I was just playing around and thought to try what would happen if I just provided one element of the timestamp in a string. If it worked, I expected it to default the missing element to either midnight or 01/01/1904. It seems it does, but does require that space after the time only element. This might be classed as "undefined behaviour" of course.
That's pretty much the definition of it yes. Strictly speaking the missing space is an error as far as the format string goes (and I'm sure the node actually returns an error in the error cluster, which is why I usually/often do use its output although most people tend to completely ignore it).
If you do use the error out you should however watch out, just blindly wiring the error cluster through like with other nodes, is almost always an error {sic}.
Basically the Scan Format String function works as follows
for param in parameters
process format string
if error then abort
The undocumented part is if a trailing constant character in the format string is still considered part of the preceding parameter or a new format element. You have found that it can be both, depending on the type of parameter (time or date).
Unexpected? You could think so, for me expecting either behavior is not something I would ever do. So I'm neutral about this being a bug or not.
If I would have to implement it, I would try to make it consistent but deliberately refrain from documenting a specific behavior.
