Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

This project is archived and is in readonly mode.

DateTime timezone support

#1501

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.


>> Time.now - 2.month
=> Wed Oct 01 10:46:12 +0200 2008
>> DateTime.now - 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.

Reported by Andre Foeken · December 1st, 2008 @ 10:10 AM

State: wontfix
Milestone: 2.x
Assigned to: Geoff Buesing Geoff Buesing
Importance: none

Activity

  1. Geoff Buesing
    Geoff Buesing

    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.

    December 1st, 2008 @ 02:24 PM

  2. josh
    josh
    • Assigned user set to Geoff Buesing

    December 8th, 2008 @ 04:58 AM

  3. Andre Foeken
    Andre Foeken

    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.

    December 8th, 2008 @ 06:23 AM

  4. Geoff Buesing
    Geoff Buesing
    • 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.

    December 9th, 2008 @ 12:03 AM