"scan from string" to timestamp doesn't work for 18:00:00 (6PM)

[MRedRaider]

I just found a strange issue in LabVIEW.  I hope I'm doing something silly, but I just may have found an unusual bug.

run the snippet below with the following for the input string: 03:00:00,18:00:00,17:00:00

Time converts fine for just about any other time EXCEPT 18:00:00 (6 PM) for which it is returned as 00:00:00 (midnight). If you even add a second to it (18:00:01) you get back the expected result.

Here's hoping I'm not loosing my mind 😉

[RavensFan]

It worked okay for me.

[Ben]

It runs perfect under LV 2011.I am in the US eastern time if that makes a difference.

Ben

Yes I stole Bills image.

[MRedRaider]

see screenshot... I guess the real question is: What broke it on my and my office mate's computers...

We've got FPGA, real time, etc. just about every toolkit that one might use for HIL development.

[MRedRaider]

More information:

We're running Windows 7 x64. Just ran the code on a fresh Win7x64 computer that only has LabVIEW and VS2010 on it, same result "00:00:00 PM"

[RavensFan]

Are you in the central timezone?

I tried your VI again, but changed it to 19:00 (since I'm in the eastern timezone).  And it failed for me.

Since there is no date, it is assuming the epoch which is midnight January 1, 1904 for GMT.  That is 7pm Dec, 31, 1903 for EST and 6pm Dec 31, 1904 for CST.  The problem with timestamps are that 0 is considered an invalid date.  Also, timestamps lose a lot of their utility when you don't have a proper date associated with it.

[MRedRaider]

Yes sir, I am in Texas, Central time.

Here's a more unusual example of the problem: Probing the wire says the value is correct but has the audacity to display 00:00:00 PM!

[MRedRaider · Accepted solution]

Well, I did find an "easy" workaround: Wire a valid default timestamp to the Scan From String premative.

Still a rather unusual reaction 🙂

[rolfk]

As annoying as it may seem, this exact scenario is an abuse of the timestamp. A timestamp is meant to be used for absolute times. And that includes a date. As Ravens Fan already pointed out, the 0 seconds since January 1, 1904 GMT is used in all timestamp display routines to mean the canonical invalid timestamp and hence the timestamp control displays the default string indicating the actual date/time format rather than a specific date/time.

If you need an absolute timestamp, for instance because you do want to have a local time indication, although the date is not relevant, adding an offset of 86400 to all values would fix it once and for all. Now the timezone offset can't cause the timestamp to reach 0 ever, even if you reside west of GMT, and it will be fine (until you start to do timestamp arithmetic that involves subtraction of relative timespans, then you would have to make the offset big enough that this will never get an issue). The current date would serve as a nice offset for that, which would be MattH's last suggestion. Nice to see that the Scan from String routine actually does use the passed in timestamp as default value and only replaces the values it is configured to parse.

[Ben]

Thanks guys.

I thought this was going to be a boring thread and now I am going to have to collect that grey matter on the floor before the Roomba gets it.

 Time is complex.

Ben