Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Time::new should treat numeric offsets as the GMT offset in seconds. #539
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:
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.