You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For example, let's say the current time is 2015-08-17T22:00:00UTC and you call "Date.today". You're going to get the following result:
Date.today
2015-08-17
Now, let's say you're working in a timezone that's ahead of UTC - for example "Australia/Sydney" (UTC+1000/UTC+1100DST). Now when we run Date.today.in_time_zone("Australia/Sydney").
Date.today.in_time_zone("Australia/Sydney")
Mon, 17 Aug 2015 00:00:00 AEST +10:00
This is due to the fact that the Date.today ignores completely any reference to timezones once created. Hence there is no relative offset between the Date.today and the timezone to reference for the in_time_zone function. Hence it uses it as the base date for the day in that timezone - which would actually be "yesterday" when compared with what "today" is in that timezone.
A corollary exists for timezones lagging UTC. If the current time is 2015-08-18T01:00:00UTC we get the following:
Date.today
2015-08-18
Date.today.in_time_zone("America/Chicago")
Tue, 18 Aug 2015 00:00:00 CDT -05:00
In order to correctly make reference to "today" in the appropriate timezone, you need to have a TZ reference in the creation of the originating "today" object.
For instance in the first example, we would get:
Time.now.in_time_zone("Australia/Sydney")
Tue, 18 Aug 2015 08:00:00 EST +10:00
Time.now.in_time_zone("Australia/Sydney").to_date
Tue, 18 Aug 2015
In the second instance we would have got:
Time.now.in_time_zone("America/Chicago")
Mon, 17 Aug 2015 20:00:00 CDT -05:00
Time.now.in_time_zone("America/Chicago").to_date
Mon, 17 Aug 2015
Hence, where dates are being used, it's better to use Time to initiate them, convert to timezone and then convert back to date to ensure that the "today" or any relative adjustment on "today" is made based on a point in time that has relative timezone differences accounted for.
Thank you for this details explanation! I've pushed this commit c4fe548 that basically makes the blog post stop mentioning Date.today. Just as you're saying Date.today is just as bad as Time.now.
Please see the test scenarios to see if they are addressing the concern above. Is there any scenario you an think of in Rails where simply replacing Date.today with Date.current would be wrong/not work the way you want?
Lets say you've got a server running UTC.
For example, let's say the current time is 2015-08-17T22:00:00UTC and you call "Date.today". You're going to get the following result:
Now, let's say you're working in a timezone that's ahead of UTC - for example "Australia/Sydney" (UTC+1000/UTC+1100DST). Now when we run Date.today.in_time_zone("Australia/Sydney").
This is due to the fact that the Date.today ignores completely any reference to timezones once created. Hence there is no relative offset between the Date.today and the timezone to reference for the in_time_zone function. Hence it uses it as the base date for the day in that timezone - which would actually be "yesterday" when compared with what "today" is in that timezone.
A corollary exists for timezones lagging UTC. If the current time is 2015-08-18T01:00:00UTC we get the following:
In order to correctly make reference to "today" in the appropriate timezone, you need to have a TZ reference in the creation of the originating "today" object.
For instance in the first example, we would get:
In the second instance we would have got:
Hence, where dates are being used, it's better to use Time to initiate them, convert to timezone and then convert back to date to ensure that the "today" or any relative adjustment on "today" is made based on a point in time that has relative timezone differences accounted for.
time-zone-article/spec/models/article_spec.rb
Lines 74 to 84 in 7bdf09f
The text was updated successfully, but these errors were encountered: