05-14-2010 10:48 PM
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.
05-15-2010 03:25 AM
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.
05-15-2010 07:50 AM
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.
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.
05-17-2010 10:47 AM
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.
05-17-2010 10:59 AM
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.
I read the release notes and upgrade notes and still I miss things!
Thanks all !
Ben