Fix TimeStamp Control and Indicator to allow all reasonable values (means changing the "unwired" value, I suspect)

[Bob_Schor]

I was recently developing some teaching material involving "time arithmetic", and (re-)discovered some peculiar anomalies with the LabVIEW TimeStamp Control and Indicator.  LabVIEW's TimeStamp is defined as "the number of seconds since midnight, 1 Jan 1904, UTC".  It is represented internally as a 128-bit number, with the first 64 bits being the number of seconds, and the second 64 bits being "fractional seconds".  If you subtract two TimeStamps, you get the "elapsed time" between them, which (if it is less than a day) is easily displayed by converting the resulting Dbl to a TimeStamp and wiring it to a TimeStamp indicator.  You need to set the Indicator to display 24-hour UTC (and no date), otherwise you'll get "local time".  In particular, if I wire the constant 0 into a Convert to TimeStamp and display this in EST, I (should) get 19:00:00.

Instead, I get 00:00:00!  If I wire 1 (second), I get the expected 19:00:01, and if I wire -1, I get 18:59:59.  I can get very-very close to 0 (0.0000000000001), and I'll get 19:00:00, but 0 gives me a "big jump" to 0:00:00.  This is something mathematicians call a "discontinuity".

I called NI, spoke to an AE, and he seemed as surprised by this (unexpected, perhaps even undocumented) behavior.  He was, however, able to find a report where someone else mentioned this, and the LabVIEW Developers chose to "leave it as it is" (no explanation that he could provide).  I've been puzzling over this, and can find only one explanation (for which I have a suggested "fix") --

LabVIEW Variables have a default (or "unwired") value, frequently 0.  For a TimeStamp, 0 mean "midnight, 1 Jan 1903", which I can understand will look "silly" as the "default" value of the TimeStamp control.  The current unwired appearance of the TimeStamp is a time of 0:00:00 PM, and an unspecified date (MM/DD/YYYY) on my machine.  This is also what is displayed when 0 is wired to it.  However, this is also the value displayed when either +inf, -inf, or NaN is wired to it.  Of course, wiring the Machine epsilon (the smallest non-zero real) produces 7 PM, the Disconcerting Discontinuity.

I maintain that, in the case of a TimeStamp Control or Indicator, a better "unwired" value would be NaN, which will currently give a "legal" display that is meaningful, i.e. a time of 0 (regardless of the time zone) and no specific date.  This would allow NI to restore the ability to let all dates and times display on a continuous scale, with the displayed value of -1 showing a second earlier than the displayed value of 0, as expected.

Recommendation -- restore the value 0 as a "legal" TimeStamp value (displaying the equivalent of midnight, 1 Jan 1904 in accordance with the TimeStamp display format) and choose a different value, perhaps NaN, as the "unwired default".  I cannot imagine that this would seriously "break" code, as it only affects the displayed value.  However, having the display exhibit a "display discontinuity" as the TimeStamp value crosses 0 seems illogical and confusing, particularly for those trying to learn to use TimeStamps.

Bob Schor

[Brian_Powell]

Darin_K is right that there are other bit patterns that would have been less intrusive as a sentinel.  We could have chosen, for example, a sentinel that was outside recorded history a few billion years ago.  But in reality, we didn't consider a sentinel until after we'd released the time stamp data type into the wild.  So we were retroactively choosing a sentinel and chose zero for convenience--e.g., we wouldn't have to change code that already assumed that zero was the default value, and we wouldn't have to come up with clever code for backwards compatibilty.  We knew we were inconveniencing people who were time stamping data from the early 20th century, but we didn't think many of our customers would care.

Also, to correct one other point... IEEE 754 "throws away" about 16 million bit patterns in a double-precision number for the sake of encoding NaNs.  (Out of about 18 quintillion values.)  These are out near the extreme maximum absolute values that the data type can encode.  I think Darin_K's point is that nobody complains much about losing those 16 million encodings, though there are certainly applications that could use them if they were available.

I don't understand the point about "any value which has an absolute value less than somewhere around 5e-20 is going to be considered NaT."  (5e-20 is the epsilon for the time stamp format.)  Is your point that there are an infinite number of points in time that can't be represented because the gap between any two points in time has to differ by at least 5e-20 for us to notice?  That's true (an issue with any fixed-size numeric encoding), but I don't understand what that has to do with a NaT encoding.

[Darin.K]

My point was simply that the control coerces more than exactly zero to display NaT, and that some tiny nonzero value could also have worked.   

[Bob_Schor]

Darin notes that any small non-zero value could have been chosen as the sentinel.  Another idea (I'm embarassed that I didn't think of it earlier) is to set all the bits -- my guess (but I haven't tested it) is that this is already NaT, and has a "LabVIEW Precedent" where -1 is used to mean "no fixed upper limit" for integer quantities such as queue lengths, or timeout milliseconds.

[RavensFan]

Here is a recent thread talking about the timestamp and the behavior with a zero value.  To Time Stamp conversion behavior

But what I find particularly interesting is the link in that thread to an NI white paper which does not mention anything at all about the 00:00:00 MM/DD/YY appearance for the "zero" timestamp.

[tst]

That white paper talks purely about the data type. Why would it say anything about the display?

[RavensFan]

Maybe it doesn't talk about the display.  But it sure was a point of confusion that the poster in the other thread thought applied.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.