I'm really lazy and always use the exact same "config/database.yml" file with my Rails projects....
Jan 27, 2012
Jan 7, 2012
Until they make the content available when people want to see it on which ever device or service they want to view it they have no footing in the argument against it being a service problem.
There's a ton more material out there but that's a good start if you're new to the topic.
Jan 6, 2012
The example above does return a time value in the current timezone and will work as expected. One big problem with strptime is that it isn't very flexible, the input string must match the provided format string exactly right down the the separator characters and spaces. So this approach can work if your processing the output of a control but tends to fail if you need to process human input.
Another problem I have with the approach above is that it quickly becomes incredibly redundant if you're working with a large number of date/time fields in many different models. To Dry that up a bit I decided to move my specialized processing into a modified version of Date._parse. This means I don't have to litter my controllers with date time parsing code and I have a single entry point to test that all desired formats are supported.
Basically all this is doing is taking the input string and re-arranging the values into an order the original method will understand. The biggest disadvantage to this problem is that it doesn't support per-locale input formats. It guess I'll cross that bridge if I ever get to it.
Assuming your local timezone is not 'UTC' you most likely will want to configure Postgres to use it anyway on your development machine so that your development environment behaves like your production environment. To do this just find the 'timezone=' line in postgresql.conf and set it to 'UTC'.
Jan 4, 2012
I'm in the middle of correcting some date/time handling in a Rails app. One of things that was wrong was the handling of user input date/time fields. Obviously when users provide date/time values they're assuming we understand the information was provided from the perspective of their timezone. Especially when we don't explicitly require them to provide timezone information.
The problem with this is that Ruby's DateTime.parse method always returns UTC based times. You can see this clearly in the example below:
You can see the problem on the 6th line in the example above. Even though the user input "2011/01/01T00:00" when that DateTime instance is converted to localtime the current timezone offset was subtracted. In this case resulting in a time that's 6 hours earlier than desired.
The solution is straight forward of course. You just have to add the inverse of the users timezone offset to the value returned from DateTime.parse as demonstrated below.
On line 4 you can see it's correct even when converted from UTC to local time.
As an alternative you could include the timezone information before parsing it but that's not always easy because you don't necessarily now the format of the user's input.
Of course all of this is generally pretty obvious but I shared just in case it can help some one less familiar with the issues.
Jan 3, 2012
It appears that by default Rails creates it's timestamps in Postgres using timestamps without time zone information. This means that if you're working directly with the database, using psql for example, and want to see local time representations you'll have to do something like this.
Specifically notice that I'm using the TIMEZONE function to re-cast the column to a timestamp with timezone. Since the columns implied timezone is 'UTC' that's what's used. Now that we have a timestamp with timezone we can convert that to local time using the "AT TIME ZONE" syntax.