2

I want to configure my Rails 4.2.5 app to use the time zone of the system it's running on (e.g. Time.current same as Time.now), without having to hard-code it into the config.

This is for compatibility with an existing legacy infrastructure that was created before I was hired. I'm fully aware of the best practice of using UTC by default, and one day we'll rewrite all of our code to use UTC as the default, but that is not an option today. Since the existing code and apps use the server's non-UTC timezone as the default, breaking that convention would break our existing code.

This is a proprietary app which runs on cloud instances that are automatically deployed using chef; individual instances are not manually administered. Therefore the OS config is the application environment config and is consistent across all instances. Also, everything runs on Linux only, so portability is not a concern.

The docs say that Time.current will return Time.now if Time.zone or config.time_zone are set. I have config.time_zone unset in application.rb, but it is still somehow set to "UTC" by default. How can I prevent this, so that Rails just uses the OS's time zone setting instead?

depquid
  • 726
  • 7
  • 20
  • 1
    Bad idea. Web servers should *never* depend on their server's time zone setting. It's too fragile. If Rails is preventing you from doing this, good for Rails! Don't try to defeat this best practice. – Matt Johnson-Pint Dec 10 '15 at 20:42
  • We deploy our own servers using chef which sets the timezone, which is used by several components of our infrastructure, of which the Rails app is only a small part. I'm trying to use the DRY best practice. Otherwise, we run the risk of various apps having different default timezones. – depquid Dec 10 '15 at 21:38
  • 1
    The danger is twofold. 1) It's far too easy for an admin to change the system time zone inadvertently, not realizing what it could be affecting, and 2) If you need to move an application from location A to location B, the data could become inconsistent. The best practice is to not rely on the system time zone, *and also* always set the system time zone to UTC to keep you from relying on the local time being meaningful and to avoid daylight saving time anomalies. See also: [the dst & tz best practice guide](http://stackoverflow.com/q/2532729/634824). – Matt Johnson-Pint Dec 11 '15 at 03:01
  • I'll even go as far as to recommend that you don't rely on Rail's default time zone setting either. Leave that on UTC, and use the appropriate time zone conversions in your application logic as necessary (I agree with the first part of house9's answer). – Matt Johnson-Pint Dec 11 '15 at 03:03
  • @MattJohnson I've updated the question to explain why 1) the system time zone won't be changed by an admin, 2) the application "location" won't change, and 3) using UTC as the default is not an option. – depquid Dec 11 '15 at 15:35

2 Answers2

2

I would recommend using UTC for config.time_zone and adjust per request based on the logged on users timezone.

You might be interested in a blog post I did on rails timezones? http://jessehouse.com/blog/2013/11/15/working-with-timezones-and-ruby-on-rails/

If you really want to set config.time_zone to a different value application wide (not recommended) you could set it to an environment variable and have your chef scripts set that environment variable during provisioning of the server

config.time_zone = ENV['LOCAL_TIME_ZONE'] || 'UTC'`

whatever you do: do NOT set config.active_record.default_timezone to :local this will lead to major headaches down the road

house9
  • 20,359
  • 8
  • 55
  • 61
  • While this is good advice for inexperienced developers starting from scratch, I have edited my question to clarify why the advice to use UTC is irrelevant to my situation. – depquid Dec 10 '15 at 22:38
  • I think using an `ENV` is going to be your best bet then – house9 Dec 10 '15 at 22:44
2

In the absence of a native Rails option for my desired configuration, I chose to use the following:

config.time_zone = File.read('/etc/timezone').strip

It isn't pretty, but since our server configurations are tightly controlled, it will work for now.

depquid
  • 726
  • 7
  • 20