[16.0][FIX] event_sale: event_date_begin/end truncated in UTC, not event's … - #1347
Open
cvinh wants to merge 1 commit into
Open
[16.0][FIX] event_sale: event_date_begin/end truncated in UTC, not event's …#1347cvinh wants to merge 1 commit into
cvinh wants to merge 1 commit into
Conversation
…own tz event.sale.report exposes event_date_begin and event_date_end as Date fields, populated directly from event.event's date_begin/ date_end (Datetime, stored UTC), with no timezone conversion. Since the fields are typed Date, the ORM's read_group never applies a timezone conversion when grouping by day (a Date has no time component to convert) - it truncates whatever value the view returns. As a result, for any event whose local timezone is far enough from UTC, records get bucketed under the wrong calendar day. For example, an event starting at 14:00 in a UTC-10 timezone is 14:00 - (-10:00) = 00:00 UTC the next day, so it appears one day later than expected once grouped. event.event already carries its own local timezone via date_tz (required, defaults from the event type or user), used by the model itself to compute date_begin_located/date_end_located. Use that same column to localize date_begin/date_end before truncating to a date, instead of leaving the raw UTC instant. The fix follows the same pattern already used in hr_attendance_report (AT TIME ZONE via a related tz column, not a hardcoded zone), so behavior stays correct regardless of which timezone a given event is configured in.
Author
|
same PR against odoo v18 here : odoo#283049 |
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
1 participant
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.
…own tz
event.sale.report exposes event_date_begin and event_date_end as Date fields, populated directly from event.event's date_begin/ date_end (Datetime, stored UTC), with no timezone conversion.
Since the fields are typed Date, the ORM's read_group never applies a timezone conversion when grouping by day (a Date has no time component to convert) - it truncates whatever value the view returns. As a result, for any event whose local timezone is far enough from UTC, records get bucketed under the wrong calendar day. For example, an event starting at 14:00 in a UTC-10 timezone is 14:00 - (-10:00) = 00:00 UTC the next day, so it appears one day later than expected once grouped.
event.event already carries its own local timezone via date_tz (required, defaults from the event type or user), used by the model itself to compute date_begin_located/date_end_located. Use that same column to localize date_begin/date_end before truncating to a date, instead of leaving the raw UTC instant.
The fix follows the same pattern already used in
hr_attendance_report (AT TIME ZONE via a related tz column, not a hardcoded zone), so behavior stays correct regardless of which timezone a given event is configured in.
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr