-
Notifications
You must be signed in to change notification settings - Fork 37
Dates and Times and Timezones (oh my!)
Notes from PR # - where we discussed and thought and learned more about Times and Dates and Timezones.
This is here to record how we are working with Times and Dates and Timezones and why. It may evolve. - Ashley 28 Nov 2017
This write up is what finally put it all together for me:
or What is the difference between Time.zone.now and Time.now
(Here's another: https://thoughtbot.com/blog/its-about-time-zones)
The explanation is excellent: simple, straightforward examples that explain the different classes and how things can end up wacky. It's not a very long read; I really recommend it.
I agree with you 2, @RobertCram and @patmbolger -- we should use Time.current
Ex:
We should use this: Time.zone.now
instead of this: Time.now
We should use this: Time.zone.today
instead of this: Time.today
Date.current
is == Time.zone.today
(for our purposes) so:
We should use this: Date.current
instead of this: Date.today
(You can see the tiny method that defines Date.current in the ActiveSupport gem: activesupport-5.1.0/lib/active_support/core_ext/date/calculations.rb)
Using Time.zone.___
everywhere possible draws explicit attention to the code being aware of the time zone, and it keeps everything similar.
Also, using Time.zone._____
will make it easy to move forward and display things in CET easily. (And easy, too, to perhaps allow individual users to set their own time zone in the future).
TMI/tldr: I currently think that it is good to leave our Rails Application time zone as UTC (the default). I need to think more deeply about this at some other time (ha!). I think that testing is the potential trouble spot, and we can address it by using the right strategies/classes/methods in our tests.