Time::new should treat numeric offsets as the GMT offset in seconds. #539

merged 1 commit into from Feb 26, 2013


None yet

2 participants


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.

headius commented Feb 26, 2013

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.

headius commented Feb 26, 2013

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.

@headius headius merged commit 069ed00 into jruby:master Feb 26, 2013

1 check passed

default The Travis build passed
@jvshahid jvshahid deleted the jvshahid:time-new branch Feb 26, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment