3

I'm upgrading an big, old, clunky Rails application's Ruby (mostly so I don't have to re-install REE on my reformatted laptop) and I'm getting bitten pretty badly by timezone issues. Basically, pulling datetimes out of the database is not converting them to local time correctly:

New System - Ruby 2.1.2, Ubuntu 14.04

>> Time.zone.name
=> "Central Time (US & Canada)"
>> ActiveRecord::Base.time_zone_aware_attributes
=> true
>> ActiveRecord::Base.default_timezone
=> :utc
>> Transaction.last.created_at
=> 2014-07-15 02:09:02 UTC
>> Transaction.last.created_at_before_type_cast
=> 2014-07-15 02:09:02 UTC
>> Transaction.last.created_at.localtime
=> 2014-07-14 21:09:02 -0500
>> exit
$ date
Mon Jul 14 22:27:50 CDT 2014

Old System - REE, Ubuntu 12.04

>> Transaction.last.created_at
=> Mon, 14 Jul 2014 22:03:11 CDT -05:00
>> Transaction.last.created_at_before_type_cast
=> Tue Jul 15 03:03:11 UTC 2014
>> Transaction.last.created_at.localtime
=> Mon Jul 14 22:03:11 -0500 2014

As you can see, I've ensured that time_zone_aware_attributes is set, the zone is set (I set it in the environment.rb), and ActiveRecord is storing the times in UTC (as expected). I'm so stumped on this. Anyone have any ideas?

Update

  before :all do
    @current_tz = Time.zone
    Time.zone = 'Pacific Time (US & Canada)'
  end

  after :all do
    Time.zone = @current_tz
  end

  it 'should report time as Pacific time' do
    shift = FactoryGirl.create(:shift)
    new_obj = Transaction.create(shift: shift, time: DateTime.new(2013, 3, 31, 0, 0, 0, 0), amount: 0)
    new_obj.reload
    I18n.localize(new_obj.time, format: :timeonly).should_not == '12:00 am' #We created it with a UTC date, but it should get I18n'd to Pacific time
  end

#en.yml
  time:
    formats:
      timeonly: "%l:%M %p"

The above test is also failing. The I18n stuff seems totally broken.

Update 2

I seem to have isolated the problem to 1.9.3 -> 2.1. Using 1.9.3 is fine, I suppose, and I guess I'll just run that on the new server until I upgrade Rails. Sad. I'd still love to hear any suggestions about fixes.

alkaloids
  • 145
  • 1
  • 9
  • 2
    I ran your code on ruby 2.1 with rails 4.0 and the output of the i18n stuff was 5:00. Perhaps an incompatibility between rails 3.0.x and ruby 2.1? The earliest version of rails that was fully compatible with ruby 2.0 was something like 3.2.16, so I wouldn't be massively surprised if there were some things that were broken in when you combine rails 3.0 with ruby 2.1 – Frederick Cheung Jul 15 '14 at 18:36
  • Correct. There are a couple of patches (one having to do with AR associations being broken) that I had to use to try to get them to be compatible, but this one was quite surprising. Upgrading the project from 3.0 to 3.2 (or 4) is not really something I have time for now... So I abandoned that goal of getting it running on Ruby 2. =) Thank you! – alkaloids Jul 16 '14 at 14:55

1 Answers1

1

Try using the I18n helpers to format/offset your time output - and force timezone (if needed)

puts I18n.localize(Transaction.last.created_at, format: :long)

Or

Time.use_zone("Central Time (US & Canada)") do
  puts I18n.localize(Transaction.last.created_at, format: :long)
end

I recommend you set your default Time.zone to UTC as well and update it for each user explicitly as needed - here is a blog post that might be helpful: http://jessehouse.com/blog/2013/11/15/working-with-timezones-and-ruby-on-rails/

house9
  • 20,359
  • 8
  • 55
  • 61
  • Thank you, that is probably good long-term, but definitely unexpected on a Ruby upgrade... This site is for a local market, so all users/operation is in one single time zone, but I am familiar with all of the set-timezone-per-user practices. – alkaloids Jul 15 '14 at 14:16
  • And also, rebuilding ALL the views for this application to use localized times like that is not really tractable. – alkaloids Jul 15 '14 at 14:17