From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
07-15-2010 09:59 AM - edited 07-15-2010 10:03 AM
Formatting a timestamp into string with $ specifier does not work; the formatted string is empty and no error is reported:
I have forced the width to 10 to show that the format is at least partially scanned but when it is omitted the timestamp field is empty.
I couldn't find this problem reported/addressed so here it is (LabVIEW 8.6)
LabVIEW, C'est LabVIEW
07-15-2010 10:12 AM - edited 07-15-2010 10:13 AM
Ohhhh... Snippets!!! Code Capture Tool is a must. Congrats!
LabVIEW, C'est LabVIEW
07-15-2010 10:29 AM
Maybe it means that time isn't money?
07-15-2010 10:33 AM - edited 07-15-2010 10:36 AM
Also, I forgot to say that I can confirm this in 2009.
And, you may wish to have a look at the about dialog of the CCT. 😉
09-18-2014 02:01 PM
I just ran into this issue with 2014. Did we ever get a CAR for this?
09-19-2014 11:56 AM
Ok looking at the format string, the expected output of the code would be "FILE2014-09-19-SN42.txt"
Instead we get "FILE -SN42.txt"
I did a quick search on CARs and found nothing specifically addressing this issue although some similar CARs were filed. I will raise this problem with our LabVIEW developers and see if we should file a CAR on it. However, I don't know how high of a priority a fix would be since there are easy workarounds for this.
Thanks,
09-19-2014 02:58 PM
I have a work around for this if anyone needs it badly I can share.
I use it to make human readable timestamp for putting into a text file.
Might not be in the format you wish for but it will give something.
09-19-2014 02:59 PM
""there are easy workarounds for this.""" Ahh there you go.
09-19-2014 07:42 PM
Yes, the simple work around is to put the timestamp first in both the string and the inputs. But this is a bug. There is no doubt about that. A high priority? Probably not. Something that should be looked for when doing a revamp of the Format String? Yep.