time format truncated, not rounded

[ensegre]

It occurred me to note that, while for instance the number 0.99 formatted (Format to String or Display format in indicator) %#.1f gives 1 , 0.99 formatted %#.1t gives 0.9 and %<%H:%M:%S%1u>t gives 00:00:00.9 . Is there something philosophical about not rounding times, which I'm missing, or is this a bug? I don't think the documentation mentions the issue.

[hooovahh]

Rounding time up?  Like traveling into the future?  That's just crazy! Rounding down is fine, it's like going into the past, you know the past exists you already were there.  But how can you round up, the world might end in those milliseconds you rounded up to, now won't you have egg on your face when you look at your data after the world has ended, and your timestamp shows data was taken after the world ended.

 

But seriously though, other than philosophical reasons, I don't know why we couldn't round up when appropriate.

[ThomasGutzler]

"Round To Nearest" accepts the timestamp input but it rounds to the nearest second.

I guess if you want "decisecond" ( ) rounding, you'll have to go through the pain of extracting the fraction of the second and rounding it as a double number and appending it again as a %#.1f.

You can't even "just" multiply the timestamp by ten, round and divide by ten. Because of floating point notation it'll turn 3517513878.594713690 into 3517513878.599999900

 

There is, however, this workaround:

[ensegre]

Yes, of course it can easily be worked around this or that other way, still wondering about the design choice. Even if the mere idea of thinking at a date to fractional seconds precision was a perversion (are we vulcanian?), isn't a bit disturbing that 0.999 %.0t gives 0?

[LogMAN]

Yes, of course it can easily be worked around this or that other way, still wondering about the design choice. Even if the mere idea of thinking at a date to fractional seconds precision was a perversion (are we vulcanian?), isn't a bit disturbing that 0.999 %.0t gives 0?

What would happen if you coerce this:

 

The Timestamp would have to coerce up which means the day would be wrong (01.01.1904 23:59:59,999 becomes 02.01.1904 00:00:00,000).

Now try that on the 31.12.1904 23:59:59,999...

I think this might be part of the reason why the Timestamp is not coerced by design.

Time is absolute (or was it relative?)... so yes it is a perversion and we are all vulcanian

[hooovahh]

The Timestamp would have to coerce up which means the day would be wrong (01.01.1904 23:59:59,999 becomes 02.01.1904 00:00:00,000).

Now try that on the 31.12.1904 23:59:59,999...

What about it?  You state the day is wrong, which is true but rounding up to the nearest second could mean the second is wrong, it doesn't invalidate the fact that you only rounded up a fraction of a second.  Yes time is absolute and relative I guess.  So if we think of it as seconds passed from some date GMT, rounding up a fraction of a second doesn't mean anything more than just rounding up that fraction of decimal.  Also your date example of rounding to another day doesn't matter to the other 23 time zones that would still be in the same day.  None of this explains why NI chose to do what they did, but in opinion this isn't much of a reason to treat timestamps different.

[drjdpowell]

Right now for me is June 19 at 13:19.  If someone asked me what day it is, they wouldn’t expect me to round up to "June 20thâ€.  

[ensegre]

Time is absolute (or was it relative?)...

 

Relative. A process which is scheduled to last for 0.9862612 sec runs in ~1 sec, not ~0 sec, if it has to be reported with precision of 1 sec.

[hooovahh]

Right now for me is June 19 at 13:19.  If someone asked me what day it is, they wouldn’t expect me to round up to "June 20thâ€.  

Right but, if I asked you to round 3517564740 (what I think is June 19 at 13:19 for you) to the nearest 86400 (24 hours) you would say the value is 3517603200, which ends up being the next day.  But I could see how this could cause confusion.

[LogMAN]

Relative. A process which is scheduled to last for 0.9862612 sec runs in ~1 sec, not ~0 sec, if it has to be reported with precision of 1 sec.

True but, if you use a stop watch with a precision of 1 sec, it would (should) show 0 sec and not 1 sec, assuming it has perfect accuracy. The question now is: What did we actually measure? Relatively spoken one second did not pass and also we are no longer at 0 seconds. Meaning that our process to measure the time is not precise enough to give a conclusive answer.

 

Right but, if I asked you to round 3517564740 (what I think is June 19 at 13:19 for you) to the nearest 86400 (24 hours) you would say the value is 3517603200, which ends up being the next day. But I could see how this could cause confusion.

Perfect example, this brings us to the question what we actually ask LabVIEW to do for us.

So if we request %#.1T we expect it to coerce right?

So assuming we have 01.01.1904 23:59:59,999 we expect it to coerce to 02.01.1904 00:00:00,0

 

What about it? You state the day is wrong, which is true but rounding up to the nearest second could mean the second is wrong, it doesn't invalidate the fact that you only rounded up a fraction of a second. ...

Now I want to write information into files, where the file name is build upon the actual date (%<%d-%m-%Y>T), however the entries within the file should be prefixed using the actual time with a precision of %#.1T. In accordance with the coercion, I now expect my file name to be something like '01.01.1904' (we didn't specify any precision, so we expect the highest precision possible, right?). The entry however would be prefixed with 02.01.1904 00:00:00,0! Only a fraction of a second changed, but the entry is (seemingly) in the wrong file.

 

Is this really a problem?

 

I can't tell if such a small 'mistake' is actually a huge problem on the large scale of projects that are done with LabVIEW. To me it would just be an annoyance (I like my files to be as accurate as possible ), so I would most likely write a wrapper to deal with it (which is the reversed role to the solution for coercion ThomasGutzler posted before).

Edited June 19, 2015 by LogMAN