Skip to content
By Sebastian Porto

Dealing with timezones effectively in Rails

We all have to deal with timezones in our Rails app sooner or later (probably sooner). In this blog post I want to share some of the tricks I have learned to deal with timezones effectively in Rails.

Do it sooner

Unless you are confident that you will never need to deal with timezones, you should think about them sooner rather than later, building your application in a way that accommodates for them from the beginning. This is one of those things that can be very difficult to include later, so I don't think it is a premature optimisation.


Some tutorials and blogposts suggest that you set the timezone in your app configuration to something known e.g. config.time_zone = 'UTC'. Unless you are only going to be dealing with only that timezone all the time I think this is unnecessary and even misleading. I suggest you don't worry about setting this at all and leave it to the server timezone.

Use datetime for storing dates

When storing dates in your database always try to use absolute time, e.g. datetime in rails. Don't use just dates (e.g. 2012-01-12 without the time part) unless you are certain that is what you need, i.e when the date is relative to the user.

Add a timezone to the users

Every user should have a timezone attribute, most likely in the database, but in early stages you can just create a method in the User class that returns a known value.

Showing the time / dates in the user's timezone

This is one of the most crucial things, each time you need to show a date / time to a user, you should convert that time to the user's timezone. For example:

Just remember to convert the timezone by using in_time_zone() before anything else.

Querying information relative to the user's timezone

The same is true for queries that should be relative to the user's timezone. For example, let's say we want to find today's appointments for a user (today as in their timezone):

starts_at =
ends_at =
Appointment.where(starts_at: starts_at).where(ends_at: ends_at)

Or use an around filter

Another strategy you can use is to always convert the timezone in each request to the user's timezone. You can do this with an around filter in your application controller.

class ApplicationController < ActionController::Base
  around_filter :set_time_zone

  def set_time_zone(&block)
    time_zone = current_user.try(:time_zone) || 'UTC'
    Time.use_zone(time_zone, &block)

In this way you don't need to convert the timezone inside your controllers, although I like the explicitness of using in_time_zone().

What if I don't have logged in users

If your are building a site that needs to show times and you don't have logged in users, setting the server time zone is not a solution either. You have the following options:

  • Use Javascript on the front end to figure out the correct time to display, based on the user's browser
  • Try this gem
  • Use the user's IP address to infer the timezone, this can be a hit or miss

Instead of having currentuser as nil consider setting currentuser to a special user object that represents a non logged in user, in that way this object can respond to normal user methods e.g. user.time_zone.

Querying from the front end

When you need to make ajax request where times are relevant the most reliable way is to use the epoch timestamps, this the number of second since January 1st, 1970 in UTC. So this is an absolute number regardless of the browser timezone.

var epoch = (new Date()).getTime() / 1000;

The in Rails convert that value to a time:[:epoch])


If you are building an application that uses server-generated views, testing is very straightforward. You can test that your timezones are working correctly by changing the timezone for the current user and checking that your views show the correct date/time for their timezone.

Integration testing with client side JS

However if you are doing integration testing that involves client side JavaScript, things get more difficult. For example the client side could get the timezone from the browser and then use that for querying the server, this is really hard to mock.

So the best strategy is to use the same timezone across the stack i.e. Browser, user model and server. To do this you need to set the application timezone in your tests to the timezone of the server running the CI. A particular gem that is very useful is timezone_local. If you are using factories you can then set the user timezone to the server timezone like this:

User.blueprint do
  time_zone { TimeZone::Local.get().name }


  • In general you don't need to worry about setting the server timezone.
  • You also don't need to worry about which methods in rails use timezones and which don't
  • Add a timezone property to the user
  • Convert the timezone when dealing with users (using intimezone)
  • Use a consistent timezone across the stack for integration testing that involves client side JS

Popular Articles by Our Team

Our expert team of designers and developers love what the do and enjoy sharing their knowledge with the world.

We Hire Only the Best

reinteractive is Australia’s largest dedicated Ruby on Rails development company. We don’t cut corners and we know what we are doing.

We are an organisation made up of amazing individuals and we take pride in our team. We are 100% remote work enabling us to choose the best talent no matter which part of the country they live in. reinteractive is dedicated to making it a great place for any developer to work.

Free Community Workshops

We created the Ruby on Rails InstallFest and Ruby on Rails Development Hub to help introduce new people to software development and to help existing developers hone their skills. These workshops provide invaluable mentorship to train developers, addressing key skills shortages in the industry. Software development is a great career choice for all ages and these events help you get started and skilled up.

  • Webinars


    Webinars are our online portal for tips, tricks and lessons learned in everything we do. Make the most of this free resource to help you become a better developer.

    Learn more about webinars

  • Installfest


    The Ruby on Rails Installfest includes a full setup of your development environment and step-by-step instructions on how to build your first app hosted on Heroku. Over 1,800 attendees to date and counting.

    Learn more about Installfest

  • Development Hub

    Development Hub

    The Ruby on Rails Development Hub is a monthly event where you will get the chance to spend time with our team and others in the community to improve and hone your Ruby on Rails skills.

    Learn more about Development Hub

Get the “reinteractive Review” Monthly Email