Bug
Decimal results after numerous arithmetic operations no longer rounded
Issue description
When a service creates decimal numbers by numerous arithemtic operations, like the total of an invoice with many positions, the result used to be persisted in the database with two decimal places, but has now 14. This is caused by changing the conversion from a simple string cast to number_format with trailing zero trimming. The string cast implicitly rounded (confirmed by a test). The new approach does not, because it is movtivated by correctly persisting decimals with a large scale.
Developer comments
In the case at hand value now reads *898,4300000000001* where it used to be *898,43*.
More complicated than expected: apparently even rounded numbers will show minimal deviations when rounded to 14 decimals.
This is tricky. In the end i reverted the changes which fixed the [11970, original bug] partially to use it only if the original method of conversion yields a string using the scientific notation. The only downside now is that it is a bit in the dark when which method is used. But the fabricated decimal places are gone and all other tests pass as well.
|
Work sessions2
Start |
2023-06-29T13:23:08
|
End |
2023-06-29T15:23:16
|
Participant |
Robert Cerny
|
Start |
2023-06-29T16:36:15
|
End |
2023-06-29T20:41:02
|
Participant |
Robert Cerny
|
|
We are sorry
This page cannot be displayed in your browser. Use Firefox, Opera, Safari, or Chrome instead.