Rails : Given that my database is in UTC, and my Time.zone US Eastern, how do I save a time in US Pacific?

Go To StackoverFlow.com

4

(I'm using Rails 3.2.3 on Ruby MRI 1.9.2)

Everything is stored centrally in UTC. This is good. Each User has a 'timezone' property. My ApplicationController has a before filter to adjust Time.zone to the User's stored timezone. This is also good.

Given the above, if my User completes a datetime select with a time, that time is expected to be in Time.zone and Rails will automatically adjust and save this as UTC. This too, is good.

Now: I wish to enable my Users to fill out a time in another time zone and then have it stored as UTC. However, Rails is expecting the completed date time select to have been filled out in the (previously set by ApplicationController) Time.zone. Therefore Rails adjusts to UTC incorrectly.

How do I achieve my goal of saving a time that has been input as being in a third time zone?

Illustration:

My usage scenario is a User in Florida adjusting a date for a Document belonging to a Hotel on the West Coast. They are looking to enter a time for the West Coast.

I'm using jQuery to style text boxes with a styled picker, so I have a method to output a string to the text box:

<%= f.text_field(:created_at, :value => adjusted_to_hotel_time(@document.created_at), :class => 'text datetime_picker') %>

def adjusted_to_hotel_time(time)
  time.in_time_zone(@current_hotel.timezone).to_s(:admin_jquery) # formatted for the jQuery datetime_picker text fields.
end

This is working perfectly, but Rails adjusts to UTC incorrectly when the @document is saved. I don't know what I don't know - how can I 'tag' the data entered in that field as being in @current_hotel.timezone, so that Rails will offset to UTC correctly when it saves the parent object?

2012-04-05 14:46
by Daniel


13

Cracked it!

Basically, the string that is submitted to params is representing a time in a Hotel's timezone. We have to use the built in 'use_zone' method to temporarily set the global Time.zone to that Hotel's.

We then pass the method a block where we produce the value that Rails is expecting, by using the timezone of the Hotel, rather than the User. That means that Rails' conversion to UTC results in the correct time in the db - as the time entered on the form has been converted to the Users timezone. The offsets have cancelled each other out, effectively.

@document.created_at = Time.use_zone(@current_hotel.timezone) {Time.zone.parse("#{params[:document][:created_at]}").in_time_zone(@current_hotel.timezone)}

We're basically changing the timezone of the Time object here without converting the actual time of that Time object when the timezone changes. (Good luck parsing that sentence!)

This looks to be working fine for me, but I've been looking at this for too long and I'd love to see a better way/more Rails-ey way of doing this!

2012-04-06 09:23
by Daniel
I don't understand the dearth of Q&A on this... I spent HOURS looking for this... Surely this is common??? Or literally the minute you scale to cross-geos you switch outside of rails?? ugh... thank you so much for doing this - james 2016-08-02 03:41
Glad it helped - Daniel 2016-08-02 08:51


2

The datetime column type only stores a date and time, but not the time-zone. You may need to create a secondary column to preserve the time zone used to interpret the UTC time saved there.

These two values could combine to re-create your initial input.

2012-04-05 14:52
by tadman
I guess, but I have no desire to store the timezone. That's extra overhead, and I'm happy with just using UTC. I just want to let the Rails internals know that "this piece of data is using a different offset to my global Time.zone, so please adjust to UTC differently. - Daniel 2012-04-05 14:56
Can you use the in_time_zone method to convert it before it's saved, then - tadman 2012-04-05 15:38
I'm looking at that right now actually, but I'm having trouble marshalling my params into a Time object. The string from the params object doesn't have an offset, and every time I try to marshall it, the newly instantiated time object is basing itself on the timezone of the local machine, so any conversions using intimezone are incorrect. Any ideas? - Daniel 2012-04-05 16:17
You might want to construct a DateTime object directly as one of the arguments you can supply is a time-zone offset. I'm not sure Time is as robust - tadman 2012-04-06 00:22
I actually tried to post my solution as an answer here yesterday, but I'm new and it wouldn't let me. I'll do it now - Daniel 2012-04-06 09:23
Ads