Get Date/Time String unexpected rounding

[raphschru]

I just noticed the function "Get Date/Time String" rounds to the nearest second when input "time stamp" is unwired, while it simply truncates when the input is wired.

I would expect the function to truncate in both cases.

I compared with "Format Date/Time String" for reference:

Fractional part > 0.5:

Fractional part < 0.5:

I guess it's a bug?

Regards,

Raphaël.

[Frozen]

Maybe I have not had enough coffee yet, but I cannot see any bug in your images or description. Please elaborate what  you think the bug is, because I think it is working as intended.

[Gregory]

Those functions are not running at the exact same time. Maybe try with the format string "%H:%M:%S%3u" to see the fractional seconds as well. Then you can tell if it's behavior or just when the function is being run.

Edit: after doing some testing, it seems like on a reasonable PC those functions do run at the same time down to the millisecond. I agree with the behavior you're seeing.

[raphschru]

---

@Frozen wrote:

Maybe I have not had enough coffee yet, but I cannot see any bug in your images or description. Please elaborate what  you think the bug is, because I think it is working as intended.

---

The important part is here:

Both instances of "Get Date/Time String" operate on the "current time":

 - the first one has an explicit Time Stamp wired from "Get Date/Time In Seconds", which gives the current time;

 - the second one has nothing wired, which defaults to using the current time as well.

In both cases, the result should be the same, but the one with the Time Stamp unwired unexpectedly rounds to the nearest second.

The code executes in less than a millisecond on any decent machine.

Maybe this is clearer with an animation:

[altenbach]

It is curious that the values differ, but rounding in timestamps has always been a little bit of a hairball (e.g. here and the link a the end)

I agree however that the values should probably match, timestamp wired or not.

[raphschru]

---

@altenbach wrote:

[...] but rounding in timestamps has always been a little bit of a hairball (e.g. here and the link a the end)

---

I find the behavior described in the linked thread quite logical (as you commented) :

 - Floating point format is used to display a "generic number", so it tries to be as accurate as possible to the real value given the limited number of digits it can display, thus rounding to the nearest value.

 - Absolute/Relative time formats are used to display an instant in time, the philosophy is that the displayed time should rather be a bit in the past than a bit in the future.

[Darren]

I have filed this issue as Bug 2847744 to LabVIEW R&D. Thanks for reporting it.

[Bob_Schor]

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

[raphschru]

Hi Bob,

---

@Bob_Schor wrote:

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".

---

---

---

Here is the context help image of this function:

I don't know where you see an input parameter that allows the user to "ask for fractions of a second", or even an input "format string". This function only produces a time string accurate to the minute or to the second (depending on the boolean input "want seconds?"). So, this function ignores the fractional part of the timestamp in all cases...

[wsimpson0050]

can you not use this?