[18.0][FIX] resource_booking: display all slots in the same time zone correctly#183
Merged
OCA-git-bot merged 1 commit intoOct 13, 2025
Merged
Conversation
…ctly When using a booking type with a resource calendar that has a different time zone than the resource itself, the slots are returned with mixed time zones. This commit normalizes the behavior and ensures that slots are always returned in the time zone of the booking type. Steps to reproduce: Create a resource with the time zone America/Guayaquil, and a calendar that starts from 06:00 to 15:00. Create a resource booking type with a new calendar that starts from 09:00 to 16:00, and set the time zone to Europe/Madrid. Before this commit, the slot displayed in the portal was 06:00, but it should have been 12:00. After this commit, the slot is displayed in the correct time zone (Madrid) at 12:00. Note: The 06:00 in America/Guayaquil corresponds to 12:00 in Madrid standard time, not during daylight saving time. The tests use a freeze date in February.
Contributor
|
Hi @ows-cloud, @pedrobaeza, |
pedrobaeza
approved these changes
Oct 13, 2025
Member
pedrobaeza
left a comment
There was a problem hiding this comment.
Fast-tracking the fw-port.
/ocabot merge patch
Contributor
|
Hey, thanks for contributing! Proceeding to merge this for you. |
Contributor
|
Congratulations, your PR was merged at af59193. Thanks a lot for contributing to OCA. ❤️ |
dnplkndll
added a commit
to ledoent/calendar
that referenced
this pull request
May 28, 2026
Forward-port of fixes dropped when [MIG] was written against an older 18.0 baseline: - OCA#183: restore _get_intervals(tz) + TZ-aware slot conversion so that portal slots always display in the booking type's time zone (Intervals replaces WorkIntervals from removed hr_work_entry_contract) - OCA#189: inject event_tz from the resource calendar on meeting creation so the calendar event carries the correct time zone from first write - OCA#214: set description on meeting only when requester_advice is set; unconditional assignment broke test_resource_booking_schedule_unschedule after odoo/odoo#223875 (Text vs HTML type mismatch) - OCA#219: honor all-day calendar events when computing busy slots using Domain.OR (replaces removed odoo.osv.expression) with start_date/ stop_date predicate; render full-day interval from analyzer's tz Signed-off-by: Don Kendall <dkendall@ledoweb.com>
dnplkndll
added a commit
to ledoent/calendar
that referenced
this pull request
May 29, 2026
Forward-port of fixes dropped when [MIG] was written against an older 18.0 baseline: - OCA#183: restore _get_intervals(tz) + TZ-aware slot conversion so that portal slots always display in the booking type's time zone (Intervals replaces WorkIntervals from removed hr_work_entry_contract) - OCA#189: inject event_tz from the resource calendar on meeting creation so the calendar event carries the correct time zone from first write - OCA#214: set description on meeting only when requester_advice is set; unconditional assignment broke test_resource_booking_schedule_unschedule after odoo/odoo#223875 (Text vs HTML type mismatch) - OCA#219: honor all-day calendar events when computing busy slots using Domain.OR (replaces removed odoo.osv.expression) with start_date/ stop_date predicate; render full-day interval from analyzer's tz Signed-off-by: Don Kendall <dkendall@ledoweb.com>
dnplkndll
added a commit
to ledoent/calendar
that referenced
this pull request
May 29, 2026
Forward-port of fixes dropped when [MIG] was written against an older 18.0 baseline: - OCA#183: restore _get_intervals(tz) + TZ-aware slot conversion so that portal slots always display in the booking type's time zone (Intervals replaces WorkIntervals from removed hr_work_entry_contract) - OCA#189: inject event_tz from the resource calendar on meeting creation so the calendar event carries the correct time zone from first write - OCA#214: set description on meeting only when requester_advice is set; unconditional assignment broke test_resource_booking_schedule_unschedule after odoo/odoo#223875 (Text vs HTML type mismatch) - OCA#219: honor all-day calendar events when computing busy slots using Domain.OR (replaces removed odoo.osv.expression) with start_date/ stop_date predicate; render full-day interval from analyzer's tz Signed-off-by: Don Kendall <dkendall@ledoweb.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When using a booking type with a resource calendar that has a different time zone than the resource itself, the slots are returned with mixed time zones. This commit normalizes the behavior and ensures that slots are always returned in the time zone of the booking type.
Steps to reproduce:
Create a resource with the time zone America/Guayaquil, and a calendar that starts from 06:00 to 15:00.
Create a resource booking type with a new calendar that starts from 09:00 to 16:00, and set the time zone to Europe/Madrid.
Before this commit, the slot displayed in the portal was 06:00, but it should have been 12:00. After this commit, the slot is displayed in the correct time zone (Madrid) at 12:00.
Note: The 06:00 in America/Guayaquil corresponds to 12:00 in Madrid standard time, not during daylight saving time. The tests use a freeze date in February.
Forward-port of #168
@Tecnativa @pedrobaeza @victoralmau could you please review this?