Fix time conversion to ms
1 unresolved thread
1 unresolved thread
Compare changes
@@ -26,7 +26,7 @@ using Time = units::time::millisecond_t;
Copyright © Eclipse Foundation, Inc. All Rights Reserved. Privacy Policy | Terms of Use | Copyright Agent
I am a bit confused on why this is necessary. Since Time is units::time::millisecond_t, I would have expected that "units::time::second(duration)" is implicitly converted to milliseconds?
Yes, it does. But the current implementation breaks our backward compatibility. We have a resolution of whole ms and the new conversion via chrono::milliseconds guarantees this resolution.
Ok, thanks for clarifying. Our use case also requires milliseconds as integers.
Maybe we could define Time as:
using Time = units::unit_t<units::time::millisecond, int, units::linear_scale>
I have not tried using int types before, so I am not sure if this would work. But could be worth trying out.
Good idea! I tested it with int64_t and in general it works. The impacts are:
What is your preference?
I am still a bit undecieded. With the second point I don't see any issues. The places which currently already require milliseconds as integer need a conversion anyway. In the modules where we do actual calculations they completly run in doubles and could still use the units literals.
The only thing that worries me with the first point is, that users might assume that the conversion from units::seconds_t to Time to works implicitly. Since this doesn't throw any compile errors, those mistakes could be hard to find.
One other idea, is it possible to define units conversions manually? I know you can specify conversion ratios, maybe this can be extended? Mabye we could implement our own conversion from units::time to mantle::Time?
I couldn't find out how to do this. The implicit conversions are defined in units.h in the unit_t class definition. I assume defining a specialization for our mantle::Time would need an invalid redefinition of class units::unit_t inside the mantleAPI code.
I still lack experience with the units extension. To make a final decision it probably requires some more experimenting. In order to move forward, I would be fine with both solutions at the moment.
I would prefer to stick closer to the units, but this could lead to missuse and hardtofind errors at the moment.
Should we discuss it in our meeting tomorrow?
changed this line in version 2 of the diff
Yes, let's discuss. I just made one last change for our backward compatibility and made the secondstotime a template again. This fixes the behaviour for floats as input.
@ckochendoerfer Can you please approve again? Since Jupp is already on leave but approved before guess he would be alright with templating the function, so we can proceed.