best practice is to store the “imprecise” amount next to it as whatever the database supports. That way, you have the auditable real value ($4.00) stored for use on reports and taxes, and the imprecise ($3.99999999898998888181)
Lol, that feels exactly like writing ‘four (4)’ in a sentence, I love it
It feels weird at first, but it really is the best safest way to store the auditable amount, and really most of the time with currency you don’t need to ever mutate it at the DB level, so why introduce the possibility at all of a precision error. One thing that is common is that you do a order by of your transactions, which is why the imprecise is useful, but then you display the string version to the user. It also keeps the precision rather than truncating the precision off (with money the .00 is important, most banks require exact precision to know that you didn’t accidentally have a rounding/truncation error)
Lol, that feels exactly like writing ‘four (4)’ in a sentence, I love it
It feels weird at first, but it really is the best safest way to store the auditable amount, and really most of the time with currency you don’t need to ever mutate it at the DB level, so why introduce the possibility at all of a precision error. One thing that is common is that you do a order by of your transactions, which is why the imprecise is useful, but then you display the string version to the user. It also keeps the precision rather than truncating the precision off (with money the
.00is important, most banks require exact precision to know that you didn’t accidentally have a rounding/truncation error)