#839 √ wontfix
Connor McKay

Time columns do not support time zones

Reported by Connor McKay | August 15th, 2008 @ 07:23 AM | in 2.x

The new support for time zones in Rails 2.1 does not apply time columns, but only to datetime and timestamp columns. I think this should be changed so that time columns undergo the same time zone conversions as datetime and timestamp columns.

The reasoning behind this is the same as for datetime and timestamp, even though time columns do not include date information: all times need to appear in the user's time zone. An example of where this would be important could be a news application that requires the submission of all prospective news items for the next day by a certain time, which is stored in the database. This time, even though it is date agnostic, still needs to appear in the user's own time zone to be understood correctly.

The attached patch adds time columns to the array of valid column types in the ActiveRecord::AttributeMethods::ClassMethods.create_time_zone_conversion_attribute? method.

Comments and changes to this ticket

  • Ernie Miller

    Ernie Miller August 15th, 2008 @ 02:05 PM

    I'm not sure I agree on this one. When only time, and not date is being persisted in the database, part of the information required to make an intelligent decision about conversion is missing. Namely, the ability to discern whether the time is during daylight savings time or not.

    You could say the assumption should be made that the current date should be used for determining offset from UTC, but at that point, I'd contend you're not really dealing with a persisted attribute of the model at all, but instead a derived value from the persisted data. That makes a pretty strong case for you to do your own conversion if that's what you want.

    I'd have to give this one a -1.

  • Geoff Buesing

    Geoff Buesing August 15th, 2008 @ 03:39 PM

    • → Tag changed from “2.1 activerecord patch tiny” to “2.1 activerecord patch”
    • → Assigned user changed from “” to “Geoff Buesing”

    To do time zone conversions, you need to work with specific points in time, and in order to convert a db time identifier like "12:30:00" to a specific point in time, you'd need to make an assumption about a date and a zone.

    I'm in agreement with Ernie here, these assumptions sound like they belong in application code, not Rails.

    Also, I'm not sure your example gives a compelling use case for time-only columns -- couldn't "next day by a certain time" be turned into a specific UTC time point, and stored in the db in a datetime column?

  • DHH

    DHH August 16th, 2008 @ 05:34 AM

    • → State changed from “new” to “wontfix”

    Agree with Ernie and Geoff.

  • Connor McKay

    Connor McKay August 16th, 2008 @ 06:02 AM

    Its a bit late to comment now, but I have to say that after I thought about it more, I think I do have to agree that this is an application assumption.

Please Login or create a free account to add a new comment.

You can update this ticket by sending an email to from your email client. (help)

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

Source available from github

The Git repository resides at http://github.com/rails

Check out the current development trunk (Edge Rails) with:

git clone git://github.com/rails/rails.git

Creating or reviewing a patch

See the contributor guide.

Creating a feature request

Please don't. If you want a new feature in Rails, you'll have to pull up your sleeves and get busy yourself. Or convince someone else to do it. See the contributor guide on how to get going. But posting them here is just going to lead to ticket root.

Creating a bug report

When creating a bug report, be sure to include as much relevant information as possible. Post the code sample that causes the problem. Preferably, alter the unit tests and show through either changed or added tests how the expected behavior is not occuring.

Security vulnerabilities should be reported via an email to security@rubyonrails.org, do not use trac for reporting security vulnerabilities. All content in trac is publicly available as soon as it is posted.

Then don't get your hopes up. Unless you have a "Code Red, Mission Critical, The World is Coming to an End" kinda bug, you're creating this ticket in the hope that others with the same problem will be able to collaborate with you on solving it. Do not expect that the ticket automatically will see any activity or that others will jump to fix it. Creating a ticket like this is mostly to help yourself start on the path of fixing the problem and for others to sign on to with a "I'm having this problem too".

Shared Ticket Bins