I have a Rails app that stores time values, and I have set a time zone in config/application.rb.
This works correctly on datetime columns, but time columns show the time in UTC, not the specified time zone.
The time on these two examples are both stored as 20:50 (UTC) in the database, but when I show it in a view the time column shows as UTC and the datetime column is correctly shown in the chosen time zone.
time2: 2000-01-01 20:50:00 UTC
datetime2: 2012-02-09 21:50:00 +0100
Is this expected behavior? Shouldn't time types also use the configured time zone?
ActiveRecord uses TimeWithZone, where methods like localtime, utc, utc? may help you.
Yes, this is expected behavior. Rails (ActiveRecord) stores times in UTC, then coverts them to whatever time zone Time.zone is set to upon rendering in the view.
I give up this, Rails seems to totally ignore config.time_zone with time attributes and just uses it for datetime attributes for reasons I don't understand. And as it seems, not many others understand it as well.
I will change the time attributes to type string and parse it to a time object when I need to work with it as a time object. If this is fixed in a later Rails release I can always change back to using time attributes, but now I need to go on, this has been holding me back for days.
But thanks for trying to help :)
Related
I have weird situation with my PostgreSQL db date value.
On my web site I have calendar for selecting a date and when I select some future date like "2018-09-23" in PostgreSQL table column it is saved as "2018-09-22 22:00:00"?
Obviously I am missing something. On web site all the time it shows okay time "2018-09-23" but at the table it is minus one day as you see above. Why?
Rails stores DateTime fields in UTC, but without marking their time zone as UTC. This corresponds to the timestamp without time zone type in postgres. So if your time zone is +2, it'll store the time as UTC (+0).
In Rails, Time.zone will return the current local timezone (you can add logic to change this by user, for example). When persisting a datetime, Rails will automatically convert the current Time.zone to UTC. However, it doesn't use the Postgres type that actually includes the time zone data, so it relies on convention to convert back and forth to the user's time zone.
If you really only care about the date, use the date type in your migration instead of Timestamp or DateTime.
Times and dates have a lot of subtle quirks and the "right" behavior depends on your use case. In some applications, you need to deal with "local" time when considering date transitions, and sometimes you need to finesse your application or database logic to think in terms of local time and sometimes you care about UTC time.
I have table which have a datetime field named date. When doing a POST in order to insert a new row, the date sent from the client (browser) looks like 2015-11-20T14:30:00+10:00 which is actually a correct date and timezone.
However, inside Postgres this date has been inserted as 2015-11-20 04:30:00.000000, which as you can see, is not at all the same as above. I know the problem is related to the timezone. But I cannot seems to figure out a fix.
For information, I have configured my app timezone :
class Application < Rails::Application
config.time_zone = 'Brisbane'
end
Ideas?
2015-11-20T14:30:00+10:00 means that the local time of 14:30 is 10 hours ahead of UTC. Your database field reflects the correct UTC value of 04:30. This is often the desired behavior, especially if the value represent a timestamp - the date and time something occured (past tense).
In PostgreSQL, there are two different types of timestamp fields (reference)
The TIMESTAMP WITH TIME ZONE field accepts an input that contains a time zone offset. It then converts the value to UTC for storage. On retrieval, it uses the session's timezone setting.
The TIMESTAMP, or TIMESTAMP WITHOUT TIME ZONE simply stores the date and time given, ignoring any offset, and not converting to UTC.
Most of the time, you should indeed use TIMESTAMP WITH TIME ZONE. You should only use TIMESTAMP WITHOUT TIME ZONE if you need to retain the local date and time value, such as in scheduling of future events and calculation of business hours. And for those scenarios, it often makes more sense to split date and time into separate DATE and TIME fields.
One last thing - if you can avoid it, avoid using Rails time zones and use standard tzdb zones. "Australia/Brisbane" is the full tzdb identifier equivalent to the Rails "Brisbane" time zone. Refer to the section on Rails time zones at the bottom of the timezone tag wiki.
I found this gem to be incredibly useful and easy for correctly setting the time https://github.com/kbaum/browser-timezone-rails
When i save a DateTime schedule_time to the DB, it saves according to my local time, but the timestamps (created_at) are saved apparently in UTC (7 hours ahead of my pacific time)
So if i submit the form setting my schedule_time for right now it will be 7 hours different than my created_at.
i need to show many users their times in their own selected zone, and i also need to compare times against each other, so i want all db entries to be in the same zone. Testing on my machine, my user has his zone saved as Pacific (-7:00), but its saving schedule_time in local time, not really UTC, so when i try to display the time back like this:
#item.schedule_time.in_time_zone(#user.time_zone)
it actually takes the stored datetime and subtracts seven hours from it giving me 7 hours before i wanted. i think the best thing is to just store all the datetimes in a uniform way so i can compare them easily.
changing this value config.time_zone = 'UTC' does nothing to change the stored format of my datetime. it stores in my local time regardless, while storing the timepstamps in real UTC.
ive also tried to reformat the datetime before storing it, with in_time_zone(#user.time_zone) but it had no effect on the stored time.
if i can just get schedule_time stored in UTC just like my timestamps are stored i could make this work! any ideas?
If you want to store schedule_time converted to UTC before storing it in the database, you can include a before_save callback in your Item model to convert it as follows:
before_save { |item| item.schedule_time = item.schedule_time.utc }
sorry i was totally on the wrong track.
the issue was with the jquery date picker i was using (will_pickdate). it returns a date and time but with a +0000 time zone offset. by default, the picker autofills with the current local time, but when i submitted that, rails basically thought it was receiving a time in UTC and added it as my local time but with +0000.
in order to store the date properly i have to keep the time and date from the picker intact, but just shift the +0000 part to something appropriate:
my_time.change(offset: user_time_zone_offset)
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?