-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug/56771 meeting timestamp in edit form not the same as in details #16567
Bug/56771 meeting timestamp in edit form not the same as in details #16567
Conversation
The system did this anyway, but now it becomes explicit
With the server now always running in UTC time, using the local time makes no sense any more
c234011
to
4c61ce1
Compare
Rubocop is complaining about the complexity of a method touched within the PR. The PR only changes the call signature of a method called from within the complained about method. Therefore, I deem it ok to not improve that method. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice refactoring 👏 It simplifies the code dealing with time zones and removes a lot of useless code which is always a good sign.
I only have some minor improvement suggestions.
Feel free to merge whenever you see fit.
For that long method rubocop is complaining about, if it's ok to keep it, then it could be # rubocop:disable Metrics/AbcSize
.
2055cf1
to
ecf9b90
Compare
ecf9b90
to
cd615f5
Compare
I'll merge this one in after the release branch for 14.6 has been created. |
The release branch for 14.6 has been created 👍🏻 |
Ticket
https://community.openproject.org/wp/56771
What are you trying to accomplish?
The PR ensures that times and time zones displayed in the meetings module are always in the time zone of the current user. The bug originally reported in the work package could not be reproduced but before, different code paths have been used for rendering the time zone and the calculation on times was in part achieved by setting the request's time to be in the current user's time.
What approach did you choose and why?
User.current.time_zone
will now always return a value. It will never benil
. Either the time zone selected by the user or the time zone set as the default (Setting.user_default_timezone
) is returned. This already used to be the case for logged in users. For those, in case no default is set, UTC is now returned. Internally, it was already handled as such as both server and database are running on UTC. The internal users (e.g.AnonymousUser
) follow the same pattern.format_time
andformat_date_as_time
have been simplified. There used to be code in there that was working with the localtime. Since a few rails versions back, the server is always running in UTC so there is no need for this code. The only times now necessary are UTC and the user's local time. The server's local time should have no effect. Those methods get their signature updated to use named parameters.formatted_time_zone_offset
is added toI18n
which will give the currently active time offset to the user's time zone compared to UTC. This is now employed throughout the meeting module.Setting.user_default_timezone
select and set the value to UTC as a default but this is not done in the scope of this PR.Merge checklist