This patch fixes two failing specs in ruby spec. I don't know what do you think about the way I'm caching the timezone for integer offsets, but I think it's simple enough that I don't care.
fix Time ruby spec. Time::new should treat numeric offsets as the GMT…
… offset in seconds.
We'd be mixing key types...but I don't really see that as a problem here, since both string (name of TZ) and integer (numeric TZ offset) wouldn't be ok to have in the same cache.
However, I wonder if the Joda call to get DateTimeZone from a numeric offset is going to return the same zone as MRI would. Investigating a bit before merging.
Ok, I confirmed that Joda appears to be using a generic TZ when given a numeric offset, which is the best we can expect:
ext-jruby-local ~/projects/jruby $ jruby -e "puts org.joda.time.DateTimeZone.forID('America/Chicago')"
ext-jruby-local ~/projects/jruby $ jruby -e "offset = -6; puts org.joda.time.DateTimeZone.forOffsetMillis(offset * 60 * 60 * 1000)"
These are both GMT-6, but only one of them has the regional information needed for DST, etc. Of course it's impossible to get the proper regional time zone from just a numeric offset, so your patch is probably as good as we can expect.
For reference: MRI gets around this by not doing anything. It always translates incoming string and numeric offsets into numeric offset and just uses that value. Joda's representation of TZ is much richer, so we're forced to always translate string and numeric offsets into a DateTimeZone. That gives us better regional representation of TZ, but means we can sometimes differ from MRI's behavior.