Current implementation produce incorrect output when Time#usec returns
integer < 100000, because to_s doesn't add leading zeros.

After a long list of discussion about the performance problem from using varargs and the reason that we can't find a great pair for it, it would be best to remove support for it for now.

It will come back if we can find a good pair for it. For now, Bon Voyage, `#among?`.

There're a lot of places in Rails source code which make a lot of sense to switching to Object#in? or Object#either? instead of using [].include?.

added find_zone and find_zone! to AS timezones and changed the AS Railtie to use find_zone! as well as adding Railtie tests
Signed-off-by: NSantiago Pastorino <santiago@wyeworks.com>

Signed-off-by: NSantiago Pastorino <santiago@wyeworks.com>

[#5344 state:committed]
Signed-off-by: NSantiago Pastorino <santiago@wyeworks.com>

ActiveSupport.escape_html_entities_in_json from true to false to match previously announced Rails 3 defaults [DHH]

Now that we have a separate internal rails_to_json, use a separate circular reference stack instead of sticking it in the options hash

    Example: ActiveSupport::JSON.backend = "JSONGem"

  All internal Rails JSON encoding is now handled by ActiveSupport::JSON.encode().  Use of #to_json is not recommended, as it may clash with other libraries that overwrite it.  However, you can recover Rails specific functionality
  if you really want to use #to_json.

    gem 'json'
    ActiveSupport::JSON.backend = "JSONGem"

    class ActiveRecord::Base
      alias to_json rails_to_json
    end

TimeWithZone#advance: leverage Hash#values_at and non-block form of #any? for a little less line noise, and a slight speedup (thanks raggi and Roman2K)