Re: Proposal for 2.0: New monetary data types

[Chris Travers <..hidden..>]

On Mon, Apr 5, 2010 at 8:51 AM, Adam Thompson <..hidden..> wrote:


> This makes sense; I wasn't aware the money type was deprecated.
> (Interesting: in SQL Server 2008 the money type "has fewer precision
> complications" than numeric, according to some docs I was reading on the
> weekend.  No idea what that means.)

Well, in PostgreSQL, the money type is deprecated, but enhancements
are still planned on the TODO.  So I have no idea what that means
other than "this doesn't work really well at present but we are
working on it."

>
>> Part 2 is a monetary subsystem for financial applications.  This will
>> include currency validation logic, date-based exchange-rate handling,
>> and the like.
>
> This is the scary part; as a one-man band, maintaining this part seems
> like a Sisyphean task.  As a community, though, it's feasible, although
> barely (IMHO).

The goal right now is to get two-three more people who work on other
financial applications to join this other project.  Right now, it's
just Demitri and me but this will hopefully change.  Ideally if this
works reasonably well, other contributors arise as well.  Even if it
just ends up being limited to the currency subsystem of LedgerSMB and
a couple of other applications, it will still be a win since we need
most of this anyway.

The major improvements for LedgerSMB would be:

1)  An ability to handle floating balances in other currencies.  For
example many Canadian users have bank accounts in both CAD and USD.
An income statement would need to address among other things fx gains
and losses on floated currencies.  This would also simplify in some
ways the handling of invoices in other currencies.

2)  It would provide more flexibility in dealing with multicurrency
problems than we currently have.

<snip>


> I still don't see how to cleanly separate the aspects of the project
> without limiting its use to decimalized currencies, but that would seem to
> be an acceptable limitation.  After all, I don't expect your average
> date/timestamp data type to support archaeological dates.  And despite my
> earlier comments about prediction, it would probably take a major
> socio-political upheaval (e.g. nuclear winter, mass die-off, luddite
> revolution, etc.) before non-decimalized currency could be introduced.  We
> probably won't be worrying about currency data types in that event anyway.

The time/date types  will support achaeological dates starting
somewhere in the 5th millenia BC....  However as long as we properly
document our use cases as being for applications addressing the needs
of current commerce, we should be fine.

Fractional math is a whole different issue.  I think we will avoid
getting into that unless a need arises, though a really good fraction
type would be pretty cool.  Imagine being able to add 1/3 + 1/6 and
get 1/2 back....  However, that's way outside the scope of this
project :-)

Best Wishes,
Chris Travers