Get Date/Time String

[MikaelH]

Is it commonly knows that the Get date/Time String can't handle Time Stamps greater than 5PM the 6th of February 2040?!?!

[smithd]

My guess would be 2040-1904 ~= 2^32 seconds. The labview timestamp is supposedly an I64 but maybe that function (since its ancient?) is 32-bit. I would bet it uses these guys:
https://zone.ni.com/reference/en-XX/help/371361J-01/lvexcode/datecstring/
https://zone.ni.com/reference/en-XX/help/371361J-01/lvexcode/timecstring/

Definitely not what I would expect.

Edited November 15, 2016 by smithd

[MikaelH]

I had to use QD "fts" (Format To String) and the format %<%Y-%m-%d>T to get it working.

[Rolf Kalbermatter]

On 15-11-2016 at 6:23 AM, smithd said:

My guess would be 2040-1904 ~= 2^32 seconds. The labview timestamp is supposedly an I64 but maybe that function (since its ancient?) is 32-bit. I would bet it uses these guys:
https://zone.ni.com/reference/en-XX/help/371361J-01/lvexcode/datecstring/
https://zone.ni.com/reference/en-XX/help/371361J-01/lvexcode/timecstring/

Definitely not what I would expect.

Your guess is very accurate! This node exists since the beginnings of multiplatform LabVIEW and the functions you mention do so too. It is logical that this node internally uses these functions.

Now, why didn't they just change the node to use the more modern timestamp functions that the Format into String uses?

Well, it's all about compatibility. While it is theoretically possible to just call the according format functions with the default timestamp format of %<%x %X>T to achieve the same, there is a good chance that the explicit code used in the two LabVIEW manager functions you mentioned, might generate a slightly different string format in some locales or OS versions, since that function queries all kinds of Windows settings to generate a local specific date and time string the very hard way. The formatting function was completely rewritten from scratch up to handle the many more possibilities of the Format into String format codes somewhere around LabVIEW 6, including the new timestamps.

So if they changed the primitive to internally just call a Format into String with the according format string, there would have been a very good chance that existing code using that primitive would have failed when it was to narrow-minded when parsing the generated string for some aspects (a very bad idea anyhow to try to parse a string containing a locale specific time or date, but I have seen that often in inherited code!).

One principle that LabVEW always has tried to follow is, that existing code that gets upgraded to a new version is simply continuing to work as before, or in the worst case is giving you an explicit warning at load time that there is something possibly going to change for a specific functionality. Testing all the possible incompatibilities with all the possible variations of OS version, language variants, etc. is a big nightmare and you still have no guarantee that you caught everything, since many of those locale settings can be customized by the user.

 

I had to use QD "fts" (Format To String) and the format %<%Y-%m-%d>T to get it working.

The format you want to use is more likely %<%X>T as that node produces a local specific data string, whereas your format string specifies a locale independent fixed format.

Edited November 22, 2016 by rolfk