All threads / DateTime causes StackError when config.time_zone set.

Ask A Question

Notifications

You’re not receiving notifications from this thread.

DateTime causes StackError when config.time_zone set.

Wouter van den Beld asked in Rails

Hi,

I have a strange problem
When i do the following method with no config.time_zone set in the application.rb it works.

def send_assignment
    @assignment = Assignment.find(params[:id])
    @assignment.update_attributes( :status => "send", :send_on => DateTime.now )

    AssignmentMailer.send_assignment(@assignment).deliver
    redirect_to @assignment, notice: Send'
  end

When i set the config.time_zone to

config.time_zone = 'Amsterdam'

i get the following error when i call the method

SystemStackError - stack level too deep:
  actionpack (4.1.5) lib/action_dispatch/middleware/reloader.rb:79:in `' 

If i remove the ruby :send_on => DateTime.now from the method i works.
So the DateTime.now causes a stack error when i set the config.time_zone.

Suggestions?

I think usually the config.time_zone complains when you set it to an invalid date option so it doesn't seem like that's the issue.

One thing to point out is that you should almost never use DateTime.now and you should always go with Time.zone.now just to be safe.

Maybe try swapping the DateTime ones out with Time.zone and see if that helps?

Hi Chris,

Thank you! that did the trick!

when i was looking for a answer why to use Time.zone.now instead of DateTime.now i found an explanation on the following site:
http://winstonyw.com/2014/03/03/time_now_vs_time_zone_now/

is it a correct assumption that all times are stored in UTC format in the database and when you call the time from the database the time is set based on the timezone set in the application.rb?

I think when you set config.time_zone that actually changes the database values and does not store them as UTC anymore. You can verify this by saving a time like 4pm and seeing if 4pm shows up in the database or a different time. If they are the same, then it means that it is not saving the times as UTC. If they are different, then that means it has converted it to UTC to save to the database.

I usually recommend saving always to UTC in the database so that in the future if you need to have custom times for all your users, you can adjust Time.zone on the fly or use the local_time gem.

Let me know what you find out about config.time_zone because I always forget if it modifies the ActiveRecord time conversion or not.

when you set the config.time_zone the time will be saved as UTC.

When i set config.time_zone = 'Europe/Amsterdam' the SQL sets the time in UTC

  SQL (0.3ms)  UPDATE "assignments" SET "send_on" = $1, "status" = $2, "token" = $3, "updated_at" = $4 WHERE "assignments"."id" = 18  [["send_on", "2015-05-07 07:49:36.908033"], ["status", "send"], ["token", "72BKmqs-aYVC56wLTmM4lgiajqrsb7YvMHDzeM-zN9lw"], ["updated_at", "2015-05-07 07:49:36.908870"]]

When i call ruby <%= @assignment.send_on %> in the view i get 2015-05-07 09:49:36 +0200

When i set config.time_zone = 'Eastern Time (US & Canada)' restart the server i get 2015-05-07 03:49:36 -0400

Awesome! That is good to know. Thanks for sharing that. TimeZones are such a pain.

Join the discussion

Want to stay up-to-date with Ruby on Rails?

Join 39,376+ developers who get early access to new tutorials, screencasts, articles, and more.

    We care about the protection of your data. Read our Privacy Policy.

    logo Created with Sketch.

    Ruby on Rails tutorials, guides, and screencasts for web developers learning Ruby, Rails, Javascript, Turbolinks, Stimulus.js, Vue.js, and more. Icons by Icons8

    © 2020 GoRails, LLC. All rights reserved.