Posted over 9 years ago. Visible to the public. Repeats.

Use Time.current / Date.current / DateTime.current on projects that have a time zone

Basically, you now need to know if your project uses a "real" time zone or :local, and if config.active_record.time_zone_aware_attributes is set to false or not.

  • With time zones configured, always use .current for Time, Date, and DateTime.

    ActiveRecord attributes will be time-zoned, and .current values will be converted properly when written to the database.
    Do not use and friends. Timezone-less objects will not be converted properly when written to the database.

  • With no/local time zone use,, or

    ActiveRecord attributes will not be time-zoned.
    Using .current would hand you UTC objects whose to_s(:db) may not convert properly.

Legacy behavior in Rails 2.3

It's been briefly mentioned in the random list of ActiveSupport goodies, but please do remember to always use Time.current instead of, etc.


Because of the way Rails and MySQL deal with time zones you would need to take care to use in projects which hold time zone information and only in those that run with the server's time. If you don't, bad things can and will happen. More information can be found that card.

Prefer "current"

Time.current decides if it wants to be a or a depending on the project settings. Using it keeps you sane and happy.

That logic is available for Time.current, Date.current and DateTime.current.

Once an application no longer requires constant development, it needs periodic maintenance for stable and secure operation. makandra offers monthly maintenance contracts that let you focus on your business while we make sure the lights stay on.

Owner of this card:

Arne Hartherz
Last edit:
about 2 years ago
by Besprechungs-PC
About this deck:
We are makandra and do test-driven, agile Ruby on Rails software development.
License for source code
Posted by Arne Hartherz to makandra dev
This website uses short-lived cookies to improve usability.
Accept or learn more