Use Date.current and Time.current #3618
Merged
Conversation
This file contains 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
houndci-bot
reviewed
Jun 17, 2019
javierm
changed the title
javierm
force-pushed
the
fix_date_today
branch
6 times, most recently
from
e5e8aee
to
6b16994
Compare
This was referenced Jun 23, 2019
javierm
force-pushed
the
fix_date_today
branch
2 times, most recently
from
addd37b
to
3dcf25b
Compare
|
Travis failure is not related to this pull request, but to issue #3642. |
javierm
force-pushed
the
fix_date_today
branch
3 times, most recently
from
38d5f81
to
b970c4c
Compare
Using Date.today and Time.now might lead to inconsistencies if the time zone the application uses is not the same as the system time zone.
So now, application zone is the one defined in `config.time_zone`, and system zone is the one in the computer where the application is running.
The dates are saved on UTC times on the database. So, for example, if living in West Australia, `Date.current.beginning_of_day` will be stored as UTC's yesterday at 15:15:00, while `Date.current.end_of_day` will be stored as UTC's today at 15:14:59. When we use the `DATE` database function, PostgreSQL will select the records with the same UTC date as the current UTC date. However, we need the records with the same application date (as defined in `config.time_zone`) as the current application date. The test passed (for us) because we were using `beginning_of_day + 3.hours` to make sure we were creating records when the date in Madrid was the same as the UTC date. Using a ruby interval for the time condition solves the problem.
Using Date.today and Time.now is a common mistake which might lead to obscure bugs. Now we're making sure we'll receive a warning when a pull request uses these methods.
While the correct usage would require an `in_time_zone` call, the code can be simplified and the relationship between the current date and the last `proposal.created_at + index.days` is now a bit easier to notice. We use the beginning of the month as the date of the first action because we expect all 8 actions to be created on the same month.
javierm
force-pushed
the
fix_date_today
branch
from
b970c4c
to
71bad63
Compare
|
Travis failures are not related to this pull request. |
smarques
pushed a commit
to venetochevogliamo/consul
that referenced
this pull request
Apr 29, 2020
Use Date.current and Time.current
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.
Background
Using
Date.todayandTime.nowmight lead to inconsistencies if the time zone the application uses is not the same as the system time zone.Objectives
Fix all possible date errors we might have when the computer the application is running uses a different time zone than the one we define in
config.time_zone.