Forum > LCL
[SOLVED] VST summation time bugs
dseligo:
--- Quote from: Pe3s on February 04, 2023, 04:30:22 pm ---The data is correct if else returns nothing. Any ideas ?
--- End quote ---
Idea is: give test data and compileable code.
WooBean:
Pe3s
I think that your usage of TryStrToTime(Data^.iGodzin, Time) leads to the error.
For returning TRUE for TryStrToTime valid parameter is from '00:00:00' to '23:59:59' (or '23:59:59.999' if your default formattings decimal separator is a dot) but not '24'!
Pe3s:
@wp, I downloaded your test application and noticed the same error if the number of rows is 21 then it counts 144 and not 168.
counts wrong on rows 21, 24, 27
What could this be due to and how can it be corrected?
wp:
Ah...
This is not a problem of VirtualTreeView, but of FormatDateTime. The reason is that 8 hours = 8/24 day = 1/3 day. This is number cannot be represented exactly as a binary value (not even as a decimal value), and adding it up for 21 days the sum is not exactly 21 x 1/3 = 7 days, but when you do a WriteLn(sum) you will see the value 6.9999999999999973E+000. The problem is that FormatDateTime in the fdoInterval mode calculates the number of full days as trunc(abs(ADateTime) * 24), i.e. the 7 days of this example turn into 6 days...
The first idea for a solution is to replace the trunc by round: It turns the 6.99999999999 into 7 - perfect. But it calls for trouble: Suppose a TTime value of 1.75, i.e. 1 full day (24 hours) + 3/4 of a full day (18 hours), in total 42 hours. But the new "round" now makes 2 full day out of the 1.75 (48 hours), plus the 18 hours we get 66...
So I guess, the trunc should remain, but only if the total value is within some tolerance near to an integer round should be used.
Requires some thoughts...
dseligo:
--- Quote from: wp on February 04, 2023, 11:21:13 pm ---This is not a problem of VirtualTreeView, but of FormatDateTime. The reason is that 8 hours = 8/24 day = 1/3 day. This is number cannot be represented exactly as a binary value (not even as a decimal value), and adding it up for 21 days the sum is not exactly 21 x 1/3 = 7 days, but when you do a WriteLn(sum) you will see the value 6.9999999999999973E+000. The problem is that FormatDateTime in the fdoInterval mode calculates the number of full days as trunc(abs(ADateTime) * 24), i.e. the 7 days of this example turn into 6 days...
The first idea for a solution is to replace the trunc by round: It turns the 6.99999999999 into 7 - perfect. But it calls for trouble: Suppose a TTime value of 1.75, i.e. 1 full day (24 hours) + 3/4 of a full day (18 hours), in total 42 hours. But the new "round" now makes 2 full day out of the 1.75 (48 hours), plus the 18 hours we get 66...
So I guess, the trunc should remain, but only if the total value is within some tolerance near to an integer round should be used.
Requires some thoughts...
--- End quote ---
I would first multiply it with 24 and then round it.
Navigation
[0] Message Index
[#] Next page
[*] Previous page