Get Date/Time String unexpected rounding

[raphschru]

---

@wsimpson0050 wrote:

can you not use this?

---

Hi, I appreciate your willingness to help, but I think your comment is (a bit) off-topic.

Please read again all the previous comments carefully.

My initial post 1 year ago was to report a bug, which was filed to NI R&D thanks to Darren.

If I had to reformulate it today, it would be:

Function "Get Date/Time String" unexpectedly rounds to the nearest second when its input timestamp is unwired.

The expected behavior for a time display is obviously to always round down because it is more preferable to be a bit in the past than a bit in the future.

The workaround is then to wire the timestamp input or to use function "Format Date/Time String" instead.

Regards,

Raphaël.

[BertMcMahan]

---

@raphschru wrote:

---

The expected behavior for a time display is obviously to always round down because it is more preferable to be a bit in the past than a bit in the future.

The workaround is then to wire the timestamp input or to use function "Format Date/Time String" instead.

Regards,

Raphaël.

---

Perhaps there is a standard somewhere that says this, but I'd disagree with "obviously" there. I would have expected it to round in BOTH cases. I agree that the behavior you're seeing is a bug, because it should at the VERY least bet the SAME for both instances.

I'd argue that it should round like any other number. I don't see a reason it should be a bit in the past rather than closer to the "actual" time. Then again, I've never needed to think about time rounding until this very thread!

Edit: I thought a bit more about it, and I'm coming around... I think you'd apply the same logic to fractional seconds to seconds that you would seconds to minutes. If I had to round the time 7:45 and 20 seconds, that's clearly 7:45. 7:45 and 50 seconds is still 7:45; I wouldn't say it's 7:46 until ten more seconds passed. Same with hours and days... at 23:59 on December 2nd, I wouldn't round it to December 3rd.

So, I suppose you're right that truncating is likely the correct behavior for time. I think I'd argue that the help should mention this fact, though.

[raphschru]

---

@BertMcMahan wrote:

---

@raphschru wrote:

---

The expected behavior for a time display is obviously to always round down because it is more preferable to be a bit in the past than a bit in the future.

The workaround is then to wire the timestamp input or to use function "Format Date/Time String" instead.

Regards,

Raphaël.

---

Perhaps there is a standard somewhere that says this, but I'd disagree with "obviously" there. I would have expected it to round in BOTH cases. I agree that the behavior you're seeing is a bug, because it should at the VERY least bet the SAME for both instances.

I'd argue that it should round like any other number. I don't see a reason it should be a bit in the past rather than closer to the "actual" time. Then again, I've never needed to think about time rounding until this very thread!

Edit: I thought a bit more about it, and I'm coming around... I think you'd apply the same logic to fractional seconds to seconds that you would seconds to minutes. If I had to round the time 7:45 and 20 seconds, that's clearly 7:45. 7:45 and 50 seconds is still 7:45; I wouldn't say it's 7:46 until ten more seconds passed. Same with hours and days... at 23:59 on December 2nd, I wouldn't round it to December 3rd.

So, I suppose you're right that truncating is likely the correct behavior for time. I think I'd argue that the help should mention this fact, though.

---

Yes thanks, this is what I was struggling to explain.

[paul_a_cardinale]

Note that the two "Get Date/Time String" don't necessarily execute at the same time.  They are very likely operating on different input values.

[paul_a_cardinale]

---

@Bob_Schor wrote:

This is NOT A BUG!  It is a (poorly-documented?) Feature.

A TimeStamp is saved as a 128-bit quantity called an "Extended Precision Float".  The high 64 bits represent the number of (whole) seconds since the 1904 (Unix?) Time-Zero base of the clock (needless to say, even earlier times are represented by negative numbers of seconds).  The low 64 bits represent the fraction of a second on the clock.  If you take the output of, say, Get Date/Time in Seconds and convert it to an Extended Precision Float, you will get a Float with a 10-digit integer part and about a 7-digit fractional part, while if you convert it to a U64, you'll just get the (same) 10-digit integer.

I'm "guessing" that "behind the scenes", LabVIEW only deals with the (numerically simpler and probably faster) high 64 (integer) bits unless the user specifically asks for "fractions of a second" (which requires delving into the low 64 bits + the "sign" bit in case of Date/Times before 1904).  So the "rounding rule" (possibly poorly-documented) is "If the user is only counting seconds and not fractions of seconds, use an Integer format, but if fractions of a second are specified (for example, with the %u format string), use the full 128-bit (unique?) Time/Stamp representation and the usual Float Rounding Rules".

Don't get me started with the Excel Variation on this topic.  About a decade ago, I figured it out "by experimentation" for myself, but I haven't thought about it in "about a decade" since then.  As I recall, Time Stamp, LabVIEW, and Excel came up before in the Forum -- I'm too lazy busy to try to find it all ...

Bob Schor

---

Note that while extended precision numbers occupy 128 bits, they only use 80 (and are often only accurate to 64 bits).  48 bits are always 0s.