Does Rail handle TimeZone by itself or we should code for it?
For example a doctor orders medicine for a patient in NewYork like 6 hours a day... then flies to California and open the chart of that patient whom had visited in NewYork and looks at his medicine schedule ... How does Rails handle this situations?
It's my understanding that Rails converts all the time types (:datetime, :time, :timestamp) to UTC before storing them in the database.
If you want to ensure local time is always shown, then you need to call TimeZone#utc_to_local on your data before displaying it.
http://api.rubyonrails.org/classes/ActiveSupport/TimeZone.html#method-i-local
There is some more good background information in this question:
In Ruby on Rails, what's the difference between DateTime, Timestamp, Time and Date?
I hope that helps.
Related
I've got an application that allows users within the same company to create job records, view, edit, and search these jobs. The users are spread out all over the United States. A user in California may need to update a job for a user in New York and visa versa.
I read through an article that suggested setting Time.zone in the controller with a before action, but if I do this, I assume that Rails would then save that record in the current time zone for like the California user. Then, if the New York user updates the same record then updated_at time would then be in a different time zone than the created_at attribute. Ideally, I see all of my records having a UTC time and then when a given user accesses/creates records, the time is displayed to them in their set timezone but saved in the database as UTC. I'm not sure how to do this or if it's even the correct approach. Can anyone provide some guidance?
Thanks in advance.
#Cannon Moyer if you see table structure of any table. updated_at and created_at columns store timestamp without timezone. When displaying, These values are automatically converted with timezone as application's timezone(UTC or IST) is set. so don't need to worry about time when a given user accesses/creates records.
For your case as #iGian suggested this gem is useful for you. It sets the Rails timezone to the browser's configured timezone for each request.
Right, this is a bit confusing for me, so I'm going to try and explain from the top!
I have a rails web app. It's an internal company app and will only be used in the UK.
One of the things the app does is manage meetings.
Meetings have a date & time when they start. There's a date/time picker on the form which allows the user to pick the date & time the meeting is for. I save this date AS IS into the database. All meetings last 2 hours, so the end time is simply start + 2 hours.
Example:
2013-06-23 6:45PM in the form is stored in the db as 2013-06-23 18:45:00
2013-12-23 6.45pm in the form is stored in the db as 2013-12-23 18:45:00
Note that the first date is during Daylight Savings (BST) and the second is during GMT. I don't actually care whether it is GMT or BST: the meeting happens at that time, absolutely.
Inside the rails webapp, I simply print out the exact date & time from the DB - formatted nicely, of course!
Now, at some point I send an email to the organiser of the meeting, and the person they're meeting with. This email tells them the the date & time of the meeting etc, and also includes an iCal (.ics) file for them to put into their (Outlook usually, but also Apple or gmail) calendar.
The issue I am having is that (using the above examples) Outlook shows the meetings like this:
Meeting #1: Start: 23/06/2013 7:45pm, End: 23/06/2013 9:45pm
Meeting #2: Start: 23/12/2013 6:45pm, End: 23/12/2013 8:45pm
Note that it has adjusted the first one because of the BST/GMT thing.
The text of the .ics file contains this code:
Meeting #1:
BEGIN:VCALENDAR
...
DTEND:20130623T204500Z
DTSTART:20130623T184500Z
...
END:VCALENDAR
Meeting #2:
BEGIN:VCALENDAR
...
DTEND:20131223T204500Z
DTSTART:20131223T184500Z
...
END:VCALENDAR
So I am encoding the dates/times using the Z timezone (UTC). I understand this is why Outlook mis converting the UTC time into the BST time for #1 and leaving #2 alone (because GMT == UTC)
My question is: how do I stop this happening? I want the time the meeting is scheduled for to be the absolute, actual time, regardless of GMT/BST: 6:45pm
Should I be storing the date-times as UTC in the DB? How would this be done (I assume it would apply to all dates, not just meeting start dates). And how to re-convert them back into the actual datetime when I display them in the webapp?
Extra:
I have an entry in my initializers/time_formats.rb like this:
:ical => "%Y%m%dT%H%M00Z"
So dates come out like "20130623T184500Z". I use this when building the ics. And this I think is the issue - if the date/time is during BST I don't want to be using Z, but something else?
Your problem is your date/time format. You have:
DTSTART:20130623T184500Z
in your .ics file and this corresponds to 19:45 BST (as British summer time is UTC+1).
There are a few things you should do. First, you can simply remove the 'Z' from the end of your dates. This means that the times inherit the timezone of the calendar, or the underlying application.
This will work assuming that the machines which are running Outlook are all in the Europe/London timezone. If not, or if you want to be a bit safer, you should also specify the following after your BEGIN: VCALENDAR line:
X-WR-TIMEZONE:Europe/London
This specifies the default timezone for all dates which are not specified explicitly.
Finally, if this does not work for any reason then you need to define your datetimes explicitly. First you need to add a timezone definition for Europe/London to the calendar. The info you need is available at http://www.tzurl.org/zoneinfo-outlook/Europe/London.ics. Then you need to ensure that all datetimes are of the format:
DTSTART;TZID=Europe/London:20130623T184500
This last approach is the best, as it means that if your requirements expand to other timezones you will be able to handle them relatively easily.
Sorry to answer this myself, but in case anyone else runs into this here's what I found was the cause of my particular issue. Note that the answer above re timezones also makes sense!
My rails app is storing UTC datetimes in the DB (as is default)
But, it also thought it's own timezone was UTC, which also seems to be the default.
The upshot of that is essentially it was storing local dates, local to UTC anyway. Changing the app to know it was sitting in Europe/London made it so the dates in the DB are all now accurately UTC (meaning, they're an hour off if I'm currently in BST)
I can now use the Z datetime format in iCals, and outlook and the rails app both convert the UTC date back into the actual datetime for the viewing-user's locale (Europe/London for everyone at the moment). This is what I wanted.
for a while I´m trying to understand how this timezone times will work, and I had a question:
Today in my country, we are in Daylight saving time (GMT-2).
So the user of my application enter a time, like 11:00AM and post the form.
Far as I know, rails will convert this date to UTC and save in the database (mysql in my case), like: 01:00PM UTC.
When I recover that record, I had to convert to local time to display. Ok?
My question is, lets suppose that this date/time represents a date/time in future, when my country gets out from summer time (GMT-3). Rails will save 01:00PM UTC? Today, in Daylight saving time, how will be the local time? And in the future, how will be this local time?
Basically, I always need to display to user 11:00AM.
thanks.
There are several places where timezone can come into play: the operating system (or probably user account) default setting, the database server, Rails environment.rb.
The key is to make sure all dates are stored with UTC time zone, then displayed in whatever your local timezone is. It sounds like you're doing that.
So your question seems to boil down to "if it's Daylight time, I want to offset by -3 hours, else offset by -2 hours". The Rails time extensions let you determine your current offset like Time.zone.now.utc_offset, and Time#dst? tells you if it's Daylight Savings Time with those two you can conditionally subtract the extra hour (3600 hundred seconds).
7 months after you asked, but perhaps skip_time_zone_conversion_for_attributes= will help - it tells AcitveRecord not to convert timezones on storage or retrieval. See ActiveRecord Timestamp which shows the example:
class Topic < ActiveRecord::Base
self.skip_time_zone_conversion_for_attributes = [:written_on]
end
I'm using Rails 3.2.8. When I generate a scaffold with a time field or datetime field. The HTML form field gets pre-populated with the current date/time in UTC. Great that it's pre-populated with the current date/time, but because it's in UTC, we have to change the time back 7 hours every time (which will sometimes require setting the day back 1 also, possibly month and year too). And then it seems the UTC time gets stored in the database, so I'll have issues displaying/editing it as well if I recorded it in our local time.
I looked at the Ruby documentation for the form helpers to deal with local time better, but I don't see anything relevant.
What's the best way to deal with editing and displaying dates and times in Rails?
UPDATE: To clarify, I like the idea that UTC time is stored in the database. I just want the time_select and datetime_select form helpers to edit the times in the user's local timezone. And, of course, I want to easily display the time in the user's local timezone.
You have to set the time zone to display on a per-user basis somewhere in a before/around_filter. This has to be done like:
Time.zone = "Kyiv"
An example can be found in its API: http://api.rubyonrails.org/classes/Time.html#method-c-zone-3D.
Run the rake time:zones:all to see all of them.
All the conversions has to be handled for you behind the scene.
This has helped me in the past. You can do things like:
Time.now.in_time_zone("Central Time (US & Canada)")
See Rails: convert UTC DateTime to another time zone
This one is driving me nuts!! The data is getting stored into the db (sqlite3) correctly. However, when I display the date from the record, Rails appears to coerce it to 1/1/2000 - with the correct time. In other words, if I specify this as the date time: December 31, 2009 6:00 PM, sqllite3 will in fact show 2009-12-31 18:00:00. But.... Rails will display the value has January 1, 2000 06:00 PM (keeping the correct time).
I have created virtual attributes to handle date formatting (which appear to work correctly). And, I have set my time zone to:
config.time_zone = 'Eastern Time (US & Canada)'
I have to believe this is something simple...It is totally driving me nuts!!
Thanks!
John
Well... I found the problem. As it turned out, when rails created the table, it did so using the Time data type. While the date portion of a datetime value will be stored in a time field, it would appear that when reading a time field, rails only considers the time portion.
The fix.. In desperation, I modified the column to be of datetime type. That fixed it.
John
I had the same problem, using postgres, and thanks user145110 for the suggestion to use the DateTime class instead of Time. That worked for me. I would only add that though I had to change my migration to use DateTime, I was still able to use Time and its methods in tests that compared against DateTime values. In other words, with this original migration:
t.time :start_time
...and sample assignment using Time:
start_time = Time.now.beginning_of_day
...it saved ok, but upon reading it later, the year was changed to 2000. Maybe it's an old Y2K bug. LOL. Instead, I simply changed the migration:
t.datetime :start_time
..and all my code worked. Even assignments like this work:
start_time = Time.zone.now.beginning_of_year.beginning_of_day
I can't help feeling like I missing something, though. Do others use Time to manipulate dates?
I was having this problem too. To add some information about the problem:
- In a debug tag (<%= debug object%>), the time and the date was correct, but when using without debug (<%= object.year %>), the year was 2000.
One can expect one of two things:
attribute:time have only the time (hours,minutes,seconds, etc.), and expect to see that information in the database (without date (year,month and day))
xor
attribute:time have time and date and that information go to the database (including the casting to the object).
Actually, rails take the two options. IMHO, this is a bug.
Am i correct? or i don't see some point of the rails design?