The comparisons with timezones ends when it comes to exchange rates. The rate at the time of transaction has to the stored (somewhere) associated with the base value. Timezones are rather fixed."
+1
No way can be solved just by type....
On Saturday, March 30, 2013, Julian wrote:
On 29/03/13 23:32, Gavan Schneider wrote: > Some people wrote: > >> ... Hmm... This should optionally apply to time. >> ... for anything that really matters, I'll work with UTC. >> > Is there a Godwin's law <http://en.wikipedia.org/wiki/Godwin's_law> > equivalent for when our conversations end up with timezones getting > mentioned? :) > > Regards > Gavan Schneider > > > Interesting discussion.
The comparisons with timezones ends when it comes to exchange rates. The rate at the time of transaction has to the stored (somewhere) associated with the base value. Timezones are rather fixed.
I went with numeric over money a long time ago (many numerous discussions in #postgresql).
As per the docs on NUMERIC: "It is especially recommended for storing monetary amounts and other quantities where exactness is required"
"However, arithmetic on numeric values is very slow compared to the integer types"
With a current WIP. I'm starting to think that numeric is probably overkill for storing monetary values as well (are we going to go much more than 6 decimal places? and thats just for storing the rates...).
Now considering just using integers. All the formatting of the input and display for output is done in the front end, just don't make a mistake there.
Boring story...
An accountant came to visit us and pulled out his calculator and started doing some simple math, he did not use the decimal point once, he always knew where it was - although I would bet he would have trouble with division.