Jump to content

Get Date/Time String


MikaelH

Recommended Posts

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 by smithd
Link to comment
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 by rolfk
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.