Geoff, wanted to chime in and thank you for rolling that in.

I just upped to edge and tested with the new changes. Solved a few
bugs I've been having issues with for a looooooong time that were
maddening.

Great work on this.

On Mar 28, 7:40 am, Geoff B <[EMAIL PROTECTED]> wrote:
> > I'd make the switch to TimeZone but I can't seem to find a proper
> > translation for the identifier strings already stored in my DB. I'm
> > willing to bet a lot of other people are in the same boat.
>
> You can find the mapping between TimeZone and TZInfo indentifiers in
> the TimeZone::MAPPING hash. Converting over should be straightforward,
> just be aware of the following:
>
> 1. TZInfo defines more zones than TimeZone does, so some TZInfo
> identifiers have no TimeZone equivalent
> 2. some TZInfo identifiers map to more than one TimeZone (e.g.,
> "America/Mexico_City" maps to both "Guadalajara" and "Mexico City")
>
> > That would save a ton of headaches. A lot of these issues I've run
> > into seem to be because of TZInfo::LinkedTimezone / TZInfo::Timezone.
> > Wrapping that class would be beautiful.
>
> Added in [9107] -- in addition to recognizing Rails TimeZone instances
> and identifiers, Time.zone= now accepts a TZInfo::Timezone instance,
> or a TZInfo/Olson identifier string (e.g., "America/New_York").
> TZInfo::Timezones are then wrapped on the fly in a Rails TimeZone.
>
> Glad you're putting the new time zone features through the paces --
> keep us posted if you run into any more issues.
>
> 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 [email protected]
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to