LabVIEW
How can I subtract timestamps to give me a DBL time in seconds?
So, if the coercion dots should not be there, will you be filing a bug report, AQ?
I have always wondered why the conversion dots were there, but since the (my) code always worked correctly I did not bother to dig deeper into that.
@JÞB wrote:
@ rolf I am aware that the value never changes but, since there is no means to show display format, I would prefer the existing coercion dots remain for code readability and maintenance.
You're clearly convoluting two very independent things here. The coercion dots have NOTHING to do with the fact, if the Timestamp control or constant from where those timestamps are coming from displays UTC or not. There is simply no direct or indirect connection between these two things. That means that the proposed Display format glyph cannot replace those red coercion dots, since they have nothing to do with each other. So NI should not keep them around until the Display Glyph is added to controls and constants but should remove them ASAP to avoid people with coercion dot phobia to do counterproductive optimization.
Even if that connection would exist between the UTC display formatting of a timestamp and the red coercion dot on the diagram, it would be a clear bug (and a pretty surprising one). Coercion dots are only supposed to be concerned about what is happening in the diagram data space, aka runtime data storage, not how a front panel control (and by extension also a diagram constant) decides to display, hide, color, paginate, rotate, transpose, and otherwise format the data display.
The red coercion dots were placed there by a developer who apparently reasoned that since a Timestamp is 128 bits and the resulting time difference is a 64 bit floating point value there must be some coercion happening.
Or alternatively (and my vote is actually on this variant) in an old version (around LabVIEW 6, when the Timestamp datatype was introduced) the addition for this datatype to the arithmetic nodes was indeed implemented quick and dirty by simply coercing the data to a double and performing the arithmetic operation in floating point space. And the node was correctly annotated with the flags that indicate that the data is getting coerced.
When that was later properly fixed the developer simply forgot to correct those flag indicators on the node definition to show what is really happening.
My reasoning for this believe is that back then, some C compilers including Visual Studio 6, which was the latest and greatest at that time, had actually a somewhat rudimentary (or maybe more properly termed experimental) 64-bit integer support and a timestamp is internally in fact a combination of 2 64-bit integers. So rather than bit fiddling on their own and trying to make sure that the 64-bit additions and subtractions add up correctly in all possible corner cases independent of the used compiler, it was easier to force the data coercion to a 64-bit floating point and let the compiler do the arithmetic on that one. That, while in reality much more complex to do than integer arithmetic, was a proven and very reliable path in all compilers back at that time. And the conversion routine from double to timestamp and vice-versa had to be developed and tested anyhow for backwards compatibility.
Visual Studio .Net, aka 2003 was the first to have a really working 64-bit integer support and Visual Studio 2005 was the first to also support 64-bit compilation and had of course to support 64-bit integer arithmetic in a 100% reliable fashion for that.
@AristosQueue (NI) wrote:
@thols wrote:
So, if the coercion dots should not be there, will you be filing a bug report, AQ?
I have always wondered why the conversion dots were there, but since the (my) code always worked correctly I did not bother to dig deeper into that.
I have to first convince others that it is a bug ("It's working just like all the other subtractions... it shows dots when input types not the same as output types..."), but I'm already working on that. 🙂
It would be nice if scripting had better access to this info.
There's a "Coercion dot?" property, but the terminal type is the wire type.
Figuring out to what the type is coerced is hard, and probably individual function specific.
Search LabVIEW like a graph! 
@JÞB wrote:
@AristosQueue (NI) wrote:
@LesHammer wrote:
True - in fact that would get rid of those conversion dots on the subtract widget of my program. 🙂No. Do not add coercion bullets. The coercion that the Subtract node is doing is not a coercion to double. It's an under-the-hood conversion that shouldn't, in my opinion, be reflected on the block diagram. If you coerce to double first, you will get the wrong answer. Coercing to double gets you a timestamp that is almost right, but not quite. You will be off by fractions of a second. It's small, but some users care about very small amounts.
These two outputs are NOT the same.
Worse, I am not sure that I agree that the Coercion dots should be hidden. Isn't the Coercion "To UTC," part of the internal storage mechanism for the timestamp? Without the Coercion dot how would we know if we were subtracting a value in System time format from one in UTC?
Casting to UTC should remove the coercion dots. No LabVIEW on my phone to test that.
If AQ had inlined a snippet everyone outside CDT could have observed the system time offset in those constants.
Actually, this could be a great zombie discussion and we can learn things!
OK So I went and lit up the old laptop.
It turns out that the only thing I was concerned about is moot! The coercion dots remain when using UTC Display Format! Dammit
Still, the fact that the result is 4 hours different than obvious in the snippet, is a considerable problem. (I consider the DST zone offset trivial and certainly expected) I had misremembered that the coersions remained and are not a helpful bug at all except for that they draw additional scrutiny of the code.
Any Visual clue would help!
