LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

The "Date/Time to Seconds" function isn't working as I expect. Can anyone tell me why?

Solved!
Go to solution

Broken Arrow wrote:
The only way to make it make sense would be to name the cluster elements properly, as NI should have done, so the names will get propigated to the Unbundle.

The NI cluster is named properly.  For whatever reason, the poster used a homemade cluster going into the bundle by name function.  You can see the coercion dot going from the bundle function to the Date/Time function.

 

If they right clicked on the NI function (before it is wired up) and select create constant.  Then wire that constant into the bundle by name function instead, then the names would look right, and there would be no coercion dot when the bundle function is wired into the NI date/time function.

Message 11 of 15
(2,352 Views)

tbob wrote:

I just looked at the detailed help on this function.  It does convert to the local time zone for your computer.  So it adjusts for DST.  I don't think it should if you have a cluster wired in.  If you wire in 11:00, it should otuput 11:00. 

 

The help says that it converts a cluster of time values into a timestamp measured as the number of seconds since blah blah blah.  But if you wire in a date time rec cluster, it doesn't output the number of seconds since blah, it outputs a timestamp of the cluster you wired in.  This function is misnamed and its help is ambiguous, if not just plain wrong. 

 

It really does not convert Date/Time to Seconds.  Its output is a timestamp, not the number of seconds since blah.  The number of seconds since blah would be a large integer, like 3,456,789 or something.  The output is not an integer, it is a timestamp.  So the name is very misleading. 

 

Also if you do not wire in the cluster, you will get a timestamp of the current time, but if you wire in a cluster, you get a timestamp of the time described by the cluster.  The help screen does not mention this at all.

 


 

I think this criticisme is a bit harsh although I agree that there are possible improvements in naming.

 

First the issue about number of seconds since, this has historical reasons as well as technical ones. For historical reasons before LabVIEW 7.1 or so, a timestamp was in fact simply a double precision float that was directly the seconds since January 1, 1904 UTC. Also a timestamp is technically still the same. It is internally a cluster of two 64 bit integers, with the first being the seconds since that ominous time and the second one being the fractional seconds. So technically a timestamp is still seconds since January 1, 1904 UTC but it is implemented such in LabVIEW that it always displays a timestamp instead. Before LabVIEW 7 you had to set the double precision float explicitedly to display a timestamp instead of the raw seconds.

 

The function does treat the cluster information as cocal time, but in newer LabVIEW versions does observe the isDST flag when doing so, overwriting the actual DST status of a particular timestamp specifically (unless you use -1 as isDST). In earlier versions of LabVIEW it simply ignored the isDST flag altogether and in even earlier versions it used the DST status of the current time irrelevant if the actual timestamp was in DST or not.

 

 

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
Message 12 of 15
(2,339 Views)

Ravens Fan wrote:

Broken Arrow wrote:
The only way to make it make sense would be to name the cluster elements properly, as NI should have done, so the names will get propigated to the Unbundle.

The NI cluster is named properly.  For whatever reason, the poster used a homemade cluster going into the bundle by name function.  You can see the coercion dot going from the bundle function to the Date/Time function.

 

If they right clicked on the NI function (before it is wired up) and select create constant.  Then wire that constant into the bundle by name function instead, then the names would look right, and there would be no coercion dot when the bundle function is wired into the NI date/time function.


Smiley Surprised My bad! Thanks Ravens. Sorry for any confusion, I should have taken the time to pop on the function's input and make a cluster.  Smiley Surprised

Richard






0 Kudos
Message 13 of 15
(2,328 Views)

rolfk wrote:

 

I think this criticisme is a bit harsh although I agree that there are possible improvements in naming.

 

 


Sometimes I can be real harsh.  However, everything I said was true.  It is my way of getting NI to make improvements.  If I had sugar coated the thing, NI would not pay attention. 

 

A simple fix in the help screen, describing the things I mentioned, and possibly a new name like Date/Time to Timestamp would be a vast improvement. 

 

I'm OK with the actual functionality, no problems here.  The first time I've used it I was really confused by the output not being an actual DBL giving the number of seconds, and the DST being observed.  I looked at the help screen and found no help at all.  Even if they don't rename it, just improving the help screen would make things right.

 

- tbob

Inventor of the WORM Global
0 Kudos
Message 14 of 15
(2,272 Views)

rolfk wrote:

...

 

(unless you use -1 as isDST). In earlier versions of LabVIEW it simply ignored the isDST flag altogether and in even earlier versions it used the DST status of the current time irrelevant if the actual timestamp was in DST or not.

 

 


Smiley Mad

 

I read the release notes and upgrade notes and still I miss things!

 

Thanks all !

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 15 of 15
(2,267 Views)