In my experience, it’s easy to accidentally leak times in the wrong time zone. I have many opinions on this topic! Our product deals with time tracking so we think about this a lot. Will repeat the tests in 2.7 to see if anything is better. Trying to re-implement Active Support’s Date/Time functionality entirely using native Time instances would be a big I’ve done some initial testing with the new timezone support in 2.6+ but didn’t see any significant performance gains to be had. However I’d suspect there may be threading issues with that and potentially performance impacts. I would certainly recommend that a server’s default timezone is UTC but Ruby’s Time.now can be switched to a different timezone by setting ENV dynamically. However if you’re wanting to do any kind of date/time math on the server then you’ll need to convert to a Time instance in a local time or an ActiveSupport::TimeWithZone so that DST boundaries are handled correctly. If all you’re doing is outputting timestamps then this is fine. Self.skip_time_zone_conversion_for_attributes = Or you can skip timezone conversion for specific attributes like this: class Post < ApplicationRecord You can either disable the conversion globally like this: config.active_record.time_zone_aware_attributes = false The only real need to deviate from that advice is where you have performance issues and by keeping things in native Time instances and disabling the timezone conversion in Active Record you can save quite a considerable amount of processing time if you’re load large numbers of records. current’ is about as simple as we can make it without patching Time.now and Date.today. Rails internally uses Time.current for methods like 24.hours.ago and ‘just use. If I had looked at this issue after 8am, I wouldn’t have seen any abnormal behavior.įor most Rails apps the advice from Thoughtbot is good starting point. Turns out the database scope responsible for this chunk uses Date.today instead of Date.current, which means when called before 8am local time, that query will return yesterday’s count. config.time_zone handles this seamlessly for the most part. This means I need to ensure that my local time is converted into UTC before sending it to the DB. However, I do want Postgres to continue storing timestamps in UTC, in case things change in future.

I don’t need to cater for users in other time zones, so the easiest approach for me to handle my local time zone is to set config.time_zone. After a few minutes, the running number resumed incrementing. A chunk of theĪpplication which was supposed to calculate a running number per number of records for today kept returning a fixed number despite new records being created. I got error reports around 7.50am and started looking into them.

Current utc time now