Purpose
=======
Buggy example:
I have a 35h working schedule. I work every week day:
- From 8h to 12h
- From 12h to 16h
Let's say that I want to retrieve the working hours from Wednesday 14h03
to Thursday 11h03.
The working hours are:
- From 14h03 to 16h --> 1h57
- From 8h to 11h03 --> 3h03
----------------------------
TOTAL 5h
Currently the result will be 1.95, i.e. 1h57 because the second day
is not taken into account as start time > end time, and thus rrule
doesn't manage this correctly and returns only the datetime corresponding
to the first day.
Specification
=============
Force the until parameter of rrule to be set at the end of the day, do
avoid skipping the second day. Do this in the methods that compute the
work hours and the leave hours.
Add a test to ensure the robustness of the fix.
Closes#21297closesodoo/odoo#28920
In the case of calculating payroll, we don't want to convert the
datetimes using the timezone of the user as we really want to see what
the employee has done from one date to another (usually from the start of
the month to end of the month)
Closes#26256closesodoo/odoo#28977
In resource.calendar.attendance, we store the start and end hour of an
interval as floats.
eg: 17 hours 9 minutes is stored as 17.15
When converting this float to a datetime object, the method
float_to_time always rounds down the value, which may be wrong if, due
to float imprecisions, 0.15 hours is converted to 8.999... minutes (and
was then rounded to 8).
We do fix this behaviour by rounding to the closest integer.
Thanks to @jem-odoo for his help troubleshooting this issue.
opw-1872166
Courtesy of Juan José Scarafía, ADHOC
The quality of the Spanish (Argentina) translations is very poor.
Remove them all and will start from scratch, translating only when needed.
Create a resource working 24 hours / day.
If we record it as:
- From 00:00 ; To 24:00 => crash
- From 00:00 ; To 23:59 => 1 minute lost
The `float_time` widget doesn't allow to be more accurate than 1 minute,
therefore it is not possible to record an end time of 23:59:59.999999.
We allow a value of 24:00 which is automatically interpreted as
23:59:59.999999. Only 1 microsecond is lost for such use case, which
should be acceptable for our level of accuracy.
opw-1856943
Christophe Simonis