You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The robot.utils.elapsed_time_to_string utility function currently accepts the elapsed time to be formatted as an integer or float representing milliseconds. This made sense earlier, because the elapsedtime attribute of our result model objects contained milliseconds as well, but as part of #4258 we now use elapsed_time that contains a timedelta. timedelta has microsecond precision and also directly support seconds with their total_seconds() method. Our utils working with milliseconds doesn't thus make much sense anymore.
The elapsed_time_to_string was already enhanced to accept the elapsed time as a timedelta, but I believe we should change it to consider ints/floats as seconds as well. Although it's unlikely this function is used outside our code base, that is certainly possible and just changing the behavior wouldn't be good. I thus believe we should deprecate the old behavior first. The problem is that the int/float value itself cannot tell should it be interpreted as seconds or milliseconds, so we need to add a new argument to control that. If the new argument is used, I believe it could be seconds=True, then the value is interpreted as seconds. If it's not used, we can interpret it as milliseconds and emit a deprecation warning.
The text was updated successfully, but these errors were encountered:
It's a bit annoying we need this kind of an utility function in the first place now that we in general use timedelta for representing elapsed times. There just doesn't seem to be any easy way to format timedelta in format hh:mm:ss[.mil]. With timestamps, that are nowadays represented as datetime, we can typically simply use datetime.isoformat().
Another thing to consider is changing the precision of elapsed_time_to_string(). As mentioned above, timedelta has microsecond precision and there might be needs to support that with elapsed_time_to_string as well. Instead of adding new include_micro argument, we probably should add timespec similarly as datetime.isoformat() has. That's a topic for another issue, though.
The
robot.utils.elapsed_time_to_string
utility function currently accepts the elapsed time to be formatted as an integer or float representing milliseconds. This made sense earlier, because theelapsedtime
attribute of our result model objects contained milliseconds as well, but as part of #4258 we now useelapsed_time
that contains atimedelta
.timedelta
has microsecond precision and also directly support seconds with theirtotal_seconds()
method. Our utils working with milliseconds doesn't thus make much sense anymore.The
elapsed_time_to_string
was already enhanced to accept the elapsed time as atimedelta
, but I believe we should change it to consider ints/floats as seconds as well. Although it's unlikely this function is used outside our code base, that is certainly possible and just changing the behavior wouldn't be good. I thus believe we should deprecate the old behavior first. The problem is that the int/float value itself cannot tell should it be interpreted as seconds or milliseconds, so we need to add a new argument to control that. If the new argument is used, I believe it could beseconds=True
, then the value is interpreted as seconds. If it's not used, we can interpret it as milliseconds and emit a deprecation warning.The text was updated successfully, but these errors were encountered: