This project is archived and is in readonly mode.

#1501 ✓wontfix
Andre Foeken

DateTime timezone support

Reported by Andre Foeken | December 1st, 2008 @ 10:10 AM | in 2.x

This might be a feature but it still seems strange to me. Time nicely uses the TimeZone but DateTime seems to fail to get the correct TimeZone.

>> - 2.month
=> Wed Oct 01 10:46:12 +0200 2008
>> - 2.month
=> Wed, 01 Oct 2008 10:46:15 +0100

If you ask for the zone of a DateTime we get "+0100" but for Time this the same method results in "CET". CET is correct. +0100 doesn't (and should not!) use daylight savings.

Tested in both 2.1.2 and 2.2.2, both fail.

Comments and changes to this ticket

  • Geoff Buesing

    Geoff Buesing December 1st, 2008 @ 02:24 PM

    Not sure what you're identifying as an issue -- is it that DateTime instances don't recognize Daylight Savings Time, or is it that the zone returns a numeric offset instead of an abbreviation (e.g., "CET")?

    Both of these issues are limitations of the Ruby DateTime class.

  • josh

    josh December 8th, 2008 @ 04:58 AM

    • Assigned user set to “Geoff Buesing”
  • Andre Foeken

    Andre Foeken December 8th, 2008 @ 06:23 AM

    I think the issue is that is feels unnatural that both classes behave so differently. I'd expect the same api to work for whatever form of Date/DateTime/Time class I use.

    I understand this may be a limitation of the Ruby classes that is difficult to change without breaking a lot of other stuff, but perhaps it might be worth it to achieve an even more uniform way of working with timezones.

    With regards to the "CET" / "+0100" line I mentioned. It was a possible indicator of the problem why the DateTime class responded differently. The generic "+0100" should not use Daylight Savings, but the more specific "CET" should. Having DateTime not differentiate between them was, in my eyes, just a possible hint to a solution.

  • Geoff Buesing

    Geoff Buesing December 9th, 2008 @ 12:03 AM

    • State changed from “new” to “wontfix”

    Given that we already have ActiveSupport::TimeWithZone and the core Ruby Time class for dst-aware time needs, I don't think it would be worth the effort, and breakage of existing functionality, to try and graft dst-awareness onto DateTime instances.

Create your profile

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

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href=""></a>

People watching this ticket