I'm having trouble working with Time.now. For some reason when I save an object to the DB it saves it for the year 2000. I'm trying to make a comparison to the object I saved in the DB to Time.now to check if it is greater, but it always returns false because of the year 2000. Does anyone know of a way I can work around this?
I just need to check to make sure 10 minutes has passed since I created a time object compared to Time.now
It sounds like your database column is of type time rather than datetime or timestamp. This will only store the time and when it is converted to a Time instance in ruby (which does support day, month, year, etc) the default values are used for day, month, year which is why you're seeing the year 2000.
You probably need to update your database column to be datetime or timestamp if that is the problem as it sounds like you'll want the day, month, year parts of the time anyway. In which case you're comparisons will work.
created_at < 10.minutes.ago should work
Related
What I need in my database could be made as such:
Migration
start_time_hours:integer
start_time_minutes:integer
end_time_hours:integer
end_time_minutes:integer
This is for saving a schedule that repeats every week and needs no other information than this. (An enum for the day, but this seems irrelevant).
Is there a way of doing this that is more the "Rails way", and less hacky?
start_time:time
end_time:time
perhaps?
And (how) would this work more efficient with forms?
Useful information: (source: Is there documentation for the Rails column types?)
Date : Stores only a date (year, month, day)
Time : Stores only a time (hours, minutes, seconds)
DateTime : Stores both date and time
Timestamp : Stores both date and time
Note: For the purposes of Rails, both Timestamp and DateTime mean the same thing (use either type to store both date and time). For the TL;DR description of why both exist, read the bottom paragraph (in source link).
So yes, you can do something like
start_time:time
end_time:time
in forms you can use an input type time
<input type="time" name="start_time">
i think this is the best way.
I would suggest:
start_time: time
duration_in_minutes: integer
In the form you have options, show start and end time and calculate the minutes before saving or show start time plus a pull down with the duration in minutes of the meeting.
My initial thought was:
user.humans.where("created_at = ?", 10.days.ago)
Though, this seems to be looking for the record created 10 days ago at the exact time when the statement is called. I want to collect the records created on that day, regardless of their time.
Is anyone aware of a convenient way to do this? Let me know if I need to elaborate.
Thanks.
You'll probably want to use a range here, as I assume this is a datetime column.
User.humans.where("? <= created_at AND created_at <= ?", 10.days.ago.beginning_of_day, 10.days.ago.end_of_day)
You'll also want to make sure you're setting the time zone of your Rails application so that you're explicit about which time period you consider to be the 10th day.
Whichever DBMS you are using will have a method to convert a datetime to a date. You should then compare this to a date in ruby. For example, if your DBMS is MySQL you could say
user.humans.where("date(created_at) = ?", 10.days.ago.to_date)
If you're not using MySQL then you should be able to google converting a datetime to a date in your DBMS of choice.
I need to compare two dates:
One date is taken form a table, created_at column and the other one is taken from (i don't know, server time, or client time).
So is it ok to compare them like this?
t.strftime("%Y-%d-%m") == Time.now.strftime("%Y-%d-%m")
Where t is the table row.create_at.
And now about, the time that my t will be compared with, from where is Time.now taken from my computer, or from the server?
If is taken from my computer, how can I use the server time?
Since Rails know that your time information is stored as UTC in the database it will convert any time you give it to UTC.
I think we should use
t.strftime("%Y-%d-%m") == Time.zone.now.strftime("%Y-%d-%m")
at the place of
t.strftime("%Y-%d-%m") == Time.now.strftime("%Y-%d-%m")
Just be sure to never construct the query string by hand and always use Time.zone.now as the base and you should be safe.
For more info, go through working with time zones
This comparison will work as expected because you are converting time to string and then comparing strings. I usually convert to integer for comparison but since you are comparing dates you would need to convert time objects to date object first.
Ruby is executed on the server so Time.now is always server time. If you want to compare with utc time use Time.current
I want to store the date of an event in my database, but I want to do so without storing informations about seconds or anything smaller than seconds. Using Rails, in my migration I have the option to create a date column or a datetime column, the first one of which is too less accurate, and the second one is too much (up to the second and less). Which type should I choose to store such a date? Currently I'm using datetime and setting the seconds to a fixed value (e.g. 0) manually each time some date is set in the model.
Something like this:
self.date ||= Time.now.change(:sec => 0)
Am I totally out of track? Should I just use an integer field for each component of the date instead? (year, month, day, etc...) Or is datetime the correct type but I'm not understanding the purpose of it? (I think it's meant for timestamps and such things where seconds matter)
datetime is the correct type. And be sure to store it without time zone at time zone UTC:
http://derickrethans.nl/storing-date-time-in-database.html
At your option, use an SQL trigger to round your date to the minute on insert/update. It'll simplify your ruby code.
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?