-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Units should be be date effective #8
Comments
I know we changed several times the unit conversion factors, but this was related to the evolution of the versions of UOM catalog. By now having the latest version was good enough, I agree for historical reasons can be interesting to go back to old wrong conversion factors, but this very special case. |
The main "need" here is to be able to reproduce results when the inputs are changed. Sometimes it's fine to use the latest version, but if you need to reproduce historical calculations (i.e. reserves calculations, production calculations, contractual results) - the need for the historical factors is very high. |
Unit conversion factors can change over time in both value and precision. Units should have a start date (and maybe end date) to enable changing the factors over time. All API's should either have an overload or a separate function call that takes and "as of" date/time.
The text was updated successfully, but these errors were encountered: