Sorry for not seeing this thread before -- the RSS feed from this group seems to be a bit flaky (anyone else noticing this?)
On Aug 21, 2:44 pm, "Michael Koziarski" <[EMAIL PROTECTED]> wrote: > > The problem is we use a shared Oracle database which has its timezone > > set to US/Pacific, and we don't have authority or the ability to > > change this. > > My (limited) understanding is that this may not actually be possible. > There are times which can't be converted from Pacific back to GMT due > to Daylight savings. Specifically when you're 'leaping back' there > are two 2:34 AMs, and when you spring forward there are none. So > taking a time in that TZ back to gmt (or to any other zone) isn't > possible. To clarify the DST conversion issue: the issue arises when you store timestamps without offest or DST info -- e.g., a MySQL datetime field, which stores timestamps in the "%Y-%m-%d %H:%M:%S" format. In zones that observe DST, during the "fall back" period there's one hour that repeats itself -- first in daylight savings time, and then in standard time. The database, however, is not given the information to disambiguate between the two: >> t1 = Time.local(2008,11,2,0,34) + 1.hour => Sun Nov 02 01:34:00 -0500 2008 >> t2 = Time.local(2008,11,2,0,34) + 2.hours => Sun Nov 02 01:34:00 -0600 2008 >> t1.to_s(:db) => "2008-11-02 01:34:00" >> t2.to_s(:db) => "2008-11-02 01:34:00" The upshot is, if you're storing local times from a DST-observing zone in a standard datetime column, you can't store the full range of time -- there would be one hour per year that you couldn't represent. > > I would be willing to put together a patch that does one of the > > following: > > > 1) Obeys the config.active_record.default_timezone setting and adjusts > > based on that > > Assuming it's possible to do this, I think that this is a fine way to > have it work. Actually, we're very close to having this working -- we'd just need to tweak TimeWithZone#to_s(:db) to report the time relative to the system local zone if config.active_record.default_timezone == :local. Granted, the datetime column caveat I explained above would be an issue with this setup, but this has always been a limitation of config.active_record.default_timezone == :local. Nate, if you still want to pull together a patch and need a bit more guidance, feel free to email me. Geoff --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
