On Mon, Apr 5, 2010 at 8:51 AM, Adam Thompson <athom...@athompso.net> 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 ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
