Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BC Date (with ActiveSupport) regression #652

Closed
kares opened this Issue Apr 24, 2013 · 2 comments

Comments

Projects
None yet
2 participants
@kares
Copy link
Member

kares commented Apr 24, 2013

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

This comment has been minimized.

Copy link
Member Author

kares commented May 18, 2013

present (same) on 1.7.4 as well

@tychobrailleur

This comment has been minimized.

Copy link
Contributor

tychobrailleur commented May 18, 2013

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"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.