Scan from String to get Timestamp, Problem in LV 2012

[RavensFan]

I have a VI I have written in LV 2013 where it works fine.  But with the same VI in LV 2012SP1, the Scan from String to get a Timestamp does not work.  Attached is the VI saved in LV2012 SP1.

Background:

I am working with an FPGA where I am clocking pulses using the 40 MHz clock.  I am logging those pulses to a file on my PXI host. To correlate the clock on the FPGA with a real life time and day for a log file, I named the file using a timestamp and the 64bit counter coded as a hex string.  Now I have a pretty good correlation between when the 64 bit counter and the time of day to aid in searching the file for data.

Now I am trying to parse the filename so in my analysis code I can reassociate the 64 bit value with the time of day by using string functions to break apart the filename.  With a few regexes (which I've never used in real life before), I've broken down the string and gotten the base time of day as a timestamp, and the base counter value as a 64-bit integer.  The VI works just fine in LV 2013.

But when I saved it to LV 2012, the scan from string to get the time stamp fails.  No error, but the timestamp shows 7 pm 12/31/1599  (I am GMT-5).  I have no idea why.  Some bug within Scan from String that was fixed in LV 2013?

Please run the attached VI in LV 2012.  Confirm if it fails for you.  Then open it in LV 2013 and see whether it works for you.

I'm trying to make it work in LV 2012 because that project is locked into that LV version for now.  I can probably do something to rearrange the time string to get something that will scan back to a numerical timestamp if I need to.

[BrotherTom]

Hi

I fiddled around with your VI in both LabVIEW versions. I don't think it's a bug but rather a change of how the "Scan from string" interprets the data. If you enter the year in a 4-digit format (20140122) in your 2012SP1 VI it works fine. But LabVIEW 2013 returns an error in this case because only 2-digit format (140122) is accepted.

Cheers

[GerdW]

Hi Raven,

there was an issue for not recognizing the year correctly in 2-digits or 4-digits mode.

LabVIEW2013 is being a more strict than older versions when scanning a timestamp with the %y/%Y format code!

Maybe you got into the some problem, but I can't open your VI at the moment…

[RavensFan]

Thanks Brother Tom and Gerd.

I tend to think this was a bug that was present in LV 2012 and fixed in LV 2013.  (Technically something had to have been wrong if it didn't work in one version and works fine in the newer version for the exact same code!)

I played with other string and format code combinations.

4 digit year string with the %Y (4 digit year) format code, also worked fine like it should

4 digit year string with the %y (2 digit year), and it worked fine, that probably shouldn't

2 digit year string with the %Y (4 digit year), and the result was interestingly wrong, correct time, but 12/31/1600 (epoch minus 302 years)

And the original problem

2 digit year string with the %y (2 digit year), result was 7pm 12/31/1599.  Basically the epoch minus 303 years minus the UTC offset)

Here are the results for LV 2013

4 digit year string with the %Y (4 digit year) format code, also worked fine like it should

4 digit year string with the %y (2 digit year), gave ERROR 1.  That is something I would expect.

2 digit year string with the %Y (4 digit year), and the result was also interestingly wrong, correct time, but 12/31/1600 (epoch minus 302 years)

And the original problem

2 digit year string with the %y (2 digit year), correct time and date was given just like I want.

It would be great if someone from NI would comment that there was an issue with the Scan from String and timestamps.  Perhaps let us know a CAR number existed.  I searched the forums for the issue and couldn't find anything related.  (I should probably search the Read Me docs for LV 2013 and see if it shows up in the bug fixes there.)  I don't know if the problem existed in LV versions before 2012.

BrotherTom, your message gave me an idea how to work around my problem most easily.  I'll just append the string "20" to the beginning of my date_time string, and use the %Y code.

Thanks for helping me investigate this.

-Bill

EDIT:  Did not see it mentioned in this document for LV 2013 http://www.ni.com/white-paper/14541/en/

[Zachmx · Accepted solution]

Hi Bill,

Sorry for being a bit late on this, I just came across this thread after tracking down the CAR for a separate issue. The fix to CAR 300375 is what is causing the difference in behavior between LabVIEW versions. It does show up on the LabVIEW 2013 Known Issues list, although the description focuses more on the issue fixed than the other possible differences between versions.

The thoughts in this thread are dead on for what happened in the fix. LabVIEW 2013 will now look for the appropriate 2- or 4-digit year string when you use the %y or %Y tags, respectively. Previously, the behavior was more forgiving in the year format, leading to the incorrect behavior you observed with 4-digit year strings and the %y tag. The original problem you pointed out (2012 incorrectly handling 2-digit year strings with the %y (2-digit) tag is specifically what was fixed in the CAR.

As for your strange result on 2-digit years with the %Y tag, this is a limitation of the Time Stamp data type itself. The year will always be coerced to between 1600 and 3000. So no extreme time travel logging. Yet.

Cheers,

[RavensFan]

Thanks Zach for replying back on this.

I couldn't find anything about there being a problem and it being fixed.  Confirmation on this helps, and I wanted to make a note of this in case anyone else searching for the same problem can find out about it.