[enhancement] internationalisation

[rwijtvliet]

Currently, all powers are converted to MW, all energies to MWh, all prices to Eur/MWh, and all revenues to Eur. In some locations, all timestamps are converted to the "Europe/Berlin" timezone.

This improvement will make the package more "universal".

Branch: internationalisation

Some desired behaviour:

When creating a PfLine, in the __init__ function a conversion of the units is no longer done before storing the df attribute. So, if the data is provided in GWh, it is stored as GWh, not as MWh (as is currently done). It is also not automatically printed in units of MWh. This will require some changes to the __repr__ function. Maybe one of the functions here may be used.

• The previous point applies everywhere, where currently a .to_baseunits() is called.

• When doing arithmatic that involves various units (e.g. adding a constant to a PfLine, or when adding 2 PfLines together), the unit of the left object is used for the resulting PfLine.

One difficulty is that we also need to specify various currencies, e.g. USD and JPY etc, in unitdefinitions.txt, while specifying that these units cannot be converted into one another. Is this something that pint can even handle? If yes, this is the preferred way, because we can use one unit registry for all commodities. This also means we can keep on using the portfolyo.Q_() class to create a valid Quantity for use with any PfLine - those that have a commodity, and those that do not. (The only thing we still need to verify that a PfLine does not mix currencies - e.g. prices in Eur/MWh and revenue in USD.)

If the previous point (various currencies) is a problem in pint when using one unit registry, we will need to create a unitregistry for each commodity. This is not preferred, because it means that PfLines can only be created when also specifying a commodity. And each commodity will likely have its own pint.UnitRegistry, which is a disadvantage, because addition etc is no longer possible. It's likely also impossible to use multiple unit registries with pint_pandas.

Tackle this issue after doing #89 and before doing #86

[rwijtvliet]

It probably makes sense to "play" with pint a bit to find out the behaviour of combining unitregistries.

For example, here we see that a meter from unitregistry1 cannot be added to a meter from unitregistry2:

import pint
>>> ureg = pint.UnitRegistry()
>>> ureg2 = pint.UnitRegistry()
>>> len1 = 1 * ureg.m
>>> len2 = 2 * ureg.m
>>> len1+len2
<Quantity(3, 'meter')>
>>> len3 = 3 * ureg2.m
>>> len1+len3
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/ruud.wijtvliet/python/portfolyo/.venv/lib/python3.11/site-packages/pint/quantity.py", line 1154, in __add__
    return self._add_sub(other, operator.add)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ruud.wijtvliet/python/portfolyo/.venv/lib/python3.11/site-packages/pint/quantity.py", line 139, in wrapped
    return f(self, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ruud.wijtvliet/python/portfolyo/.venv/lib/python3.11/site-packages/pint/quantity.py", line 1032, in _add_sub
    if not self._check(other):
           ^^^^^^^^^^^^^^^^^^
  File "/Users/ruud.wijtvliet/python/portfolyo/.venv/lib/python3.11/site-packages/pint/util.py", line 846, in _check
    raise ValueError(
ValueError: Cannot operate with Quantity and Quantity of different registries.

That would be the disadvantage of creating a unit registry for each Commodity: it would make it impossible to add a revenue-PfLine with a commodity germanpower to a revenue-PfLine with a commodity germangas - even though, it's the same Euros being added together.

And it's why it's preferred to use the same unitregistry for each Commodity and therefore for each PfLine.