Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

BC Date (with ActiveSupport) regression #652

Closed
kares opened this Issue · 2 comments

2 participants

@kares
Collaborator

I've been just hit by this while testing AR-JDBC (BC Date) support and seems to me like a JRuby 1.7.3 issue, affecting mostly --1.9 mode, I've only managed to reproduce with ActiveSupport (3.2.13) loaded so far (my local TZ is +0100) :

1.7.3 --1.9 wrong BC Date: 1753-08-29 22:43:40 +0057

>> JRUBY_VERSION
=> "1.7.3"
>> RUBY_VERSION
=> "1.9.3"
require 'active_support/all'
=> true
>> ActiveSupport::VERSION::STRING
=> "3.2.13"
Date.new(0) - 1.second
=> 1753-08-29 22:43:40 +0057

1.7.3 --1.8 correct

>> JRUBY_VERSION
=> "1.7.3"
>> RUBY_VERSION
=> "1.8.7"
require 'active_support/all'
=> true
>> ActiveSupport::VERSION::STRING
=> "3.2.13"
Date.new(0) - 1.second
=> Wed, 31 Dec -0001 23:59:59 +0100

1.6.8 --1.9 seems to work "better" (although there's the suspicious +0057 part)

>> JRUBY_VERSION
=> "1.6.8"
>> RUBY_VERSION
=> "1.9.2"
>> require 'active_support/all'
=> true
>> ActiveSupport::VERSION::STRING
=> "3.2.13"
>> Date.new(0) - 1.second
=> -0001-12-31 23:59:59 +0057

MRI 1.9.3 to be complete

>> require 'active_support/all'
=> true
>> RUBY_VERSION
=> "1.9.3"
>> ActiveSupport::VERSION::STRING
=> "3.2.13"
>> Date.new(0)
=> Thu, 01 Jan 0000
>> Date.new(0) - 1.second
=> -0001-12-31 23:59:59 +0100
@kares
Collaborator

present (same) on 1.7.4 as well

@tychobrailleur
Collaborator

The problem is in RubyTime#opPlusNanos, where we store -62167217700000 (unix time of Date.new) multiplied by 1000000 in a long, which doesn't fit, so the value becomes incorrect. The reason for this is that the add is done to the nanosecond precision – whereas in 1.6.8 it was to the millisecond, hence the issue wasn’t there.

I have managed to fix this locally by using BigInteger, but I wonder if this is the right way to go, as for consistency, it should be done in several places in RubyTime, and I am worried this may have a performance impact.

As for the timezone value, this is coming from joda:

require 'joda-time-2.2.jar'

java_import 'org.joda.time.DateTime'
java_import 'org.joda.time.DateTimeZone'

dt = DateTime.new(0, 1, 1, 0, 0, 0, 0, DateTimeZone::UTC)
dt.to_s # => "0000-01-01T00:00:00.000Z"
dt.withZoneRetainFields(DateTimeZone.getDefault()).to_s # => "0000-01-01T00:00:00.000-00:25"
@headius headius closed this in #745
@donv donv referenced this issue from a commit in DatekWireless/activerecord-jdbc-adapter
@kares kares omit bc timestamp test (potsgres) on 1.7.3 due an issue with `Date.ne…
…w(0)`

reported as jruby/jruby#652
b7182b3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.