LabVIEW
How can I subtract timestamps to give me a DBL time in seconds?
@AristosQueue (NI) wrote:
@billko wrote:
What prompted you to post to an 18 year old topic? 😄 I mean, this is good info, but...?Someone was using coercion bullets in their diagram and cited this as their reasoning. It's still the number one hit on Google for info on the topic. 🙂
At any rate I did file that in my "important to know" folder. Thanks!
@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!
@JÞB wrote:
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!
It's slightly different than you put it here. The Timestamp value itself is ALWAYS in seconds since January 1, 1904 GMT. For pretty much all practical purposes this is equal to UTC, although that didn't exist back then. 😀
What changes is the formatting of how that data is displayed. If the constant or control has the flag to display in local time, which is the default, it will change the value that is displayed, but the value behind the Timestamp remains the same.
Consider this the same as when you have a numerical control and you change its display mode from decimal to hexadecimal. Nothing on the actual numeric bits that represent the numbers stored in the control really changes, just the formatting of how the data is displayed is changed. So the UTC or local time is not part of the data in the wire/control, but an attribute of the control/constant that tells it how to display that data.
Consequently when you put time constants into your program you should consider how they are meant to be used. And here things get hairy as the intuitive approach actually will fail you quite often.
You could argue that that is wrong and it should be the opposite. However no matter how you implement it, there are always situations where it feels actually wrong. I think that the current approach is a pretty valid one and is consistent with most computer programming. The Unix timestamp is also an integer value with 1 second resolution and with epoch January 1, 1970 UTC. And the Windows FILETIME is a Quad (64-bit Integer) with 100ns intervals since January 1, 1600 UTC. Microsoft likely chose this epoch to avoid the problems with the discontinuity that occured with the change from the Julian to the Gregorian calendar in 1582, respectively even later in some countries.
The binary timestamp stored in a file will look different on a system in a different timezone when displayed in default local time format but actually does mean the exact date and time the timestamp was stored in that file when looking at it from a universal viewpoint. An observer who is not on the earth surface doesn't really care about the local timezone on earth a sun flare was recorded but the absolute "star" time. 😁
I think you still mix up things here. The coercion dot is meant to indicate that something in the numeric representation inside the wire is changing (I'm considering the pass over from a terminal to a wire and back also part of this for the ease of this discussion). The information if a timestamp is displayed in UTC or local time is however an attribute of the control itself and has nothing to do with the actual data stored in it and even less with any storage size change or whatsoever.
As such you bring up a good Idea Exchange point: "Add a glyph to the Timestamp control, constant and every other element that can display a timestamp that indicates that the timestamp displays in local time or UTC! In principle the same idea that lets also show in a string control if the string is displayed in normal, /, password, or hex mode."
Because it is really the same thing. It's about how the control displays its actual data.
