@kaikreuzer I think the currency issues should be discussed here.

I found an interesting JavaDoc for AbstractUnit which made me wonder if we need it that complex:

The class represents units founded on the seven SI base units for seven base quantities assumed to be mutually independent.
For all physics units, unit conversions are symmetrical: u1.getConverterTo(u2).equals(u2.getConverterTo(u1).inverse()). Non-physical units (e.g. currency units) for which conversion is not symmetrical should have their own separate class hierarchy and are considered distinct (e.g. financial units), although they can always be combined with physics units (e.g. "€/Kg", "$/h").

And this is of course correct, the exchange rate for €/$ is not the same as for $/€, because buying and selling has to be treated differently. But do we want it that complex of can we assume that (€ to $) = 1 / ($ to €)? In that case it would be much simpler and we could extend AbstractUnit and use much more code that is already there.

Uh oh!

Currency type UoM #3408

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions