I think this is a very important topic, but you posted it in the ruby-forum. You should repost it over in the rails forum or on the rails google group.
As for my opinion on the matter, I think AR should not be setting the time itself and it should be using the database NOW function. > Idea 2: Mixin new modules to ActiveRecord::Base to override the > transaction() call, record the time, and then call super(). Also > override > the Timestamp current_time_from_proper_timezone method to return the > time > that our transaction() call squirrelled away. Theres a little more to > this > (clearing the timestamp when the transaction is committed or rolled > back), > but you get the idea > Thoughts: Modifies ActiveRecord::Base to be more different than might be > obvious. We think we prefer the next idea (3). > > Idea 3: Subclass ActiveRecord::Base (to say ActiveRecordLocal) and mix > in > the modules mentioned above into this class. > Thoughts: This makes is clearer that when you're using > ActiveRecordLocal, > you're not getting the stock ActiveRecord::Base behavior. Otherwise this > solution is identical to Idea 2. > > Idea 4: when then transaction starts, use Timecop::freeze to freeze the > time that ruby sees. > Thoughts: We can't freeze the time for all code in the app while a > transaction is pending. Plus Timecop is for testing, not production > use-- > but most importantly see previous point. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/28a86d831081ac9baf25be31fa950d5e%40ruby-forum.com. For more options, visit https://groups.google.com/d/optout.
