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.