ActiveSupport assumes that DateTime#<=> is implemented by Date#<=> when monkey patching it, which breaks home_run (see rails/rails#2797). Since it's been over 6 months since the issue was opened and the ActiveSupport maintainers haven't expressed an interest in fixing this issue, it's better to just modify home_run to work around the ActiveSupport bug.
Previously, home_run ignored the fractional part. This commit makes home_run mirror the 1.9.3 behavior of raising an exception if a floating point argument is first and there is more than a single argument.
… bump version to 1.0.3 I've only seen this segfault when running Sequel's default rake task with home_run loaded on OpenBSD amd64. Even though rb_ary_push is given the correct arguments, a segfault still occurs in rb_ary_store. Unfortunately, it doesn't happen if you build ruby in debug mode, so I can't tell why it occurs. My best guess is it is due to an unforunate interaction between ruby and OpenBSD malloc which only happens on amd64 and only when memory happens to be laid out a certain way. This commit avoids the issue by using rb_ary_new4 and a temporary C array instead of using a blank ruby array and rb_ary_push to add items to it. I also tried increasing the integer passed to rb_ary_new2 as well as using rb_ary_new instead of rb_ary_new2, which seemed to reduce the frequency of the error, but not eliminate it completely.
Also, change dup and clone to call super instead of using DUPSETUP and CLONESETUP. This makes dup and clone work correctly on rubinius. It also makes dup and clone work correctly for Date on jruby, but not for DateTime due to a bug in JRuby. allocate is defined to use the julian day 0 for simplicity.
For some unknown reason, defining Date::Format::ZONES in C was causing the occassional segfault when loading home_run, either in an rb_hash_aset call or when freezing the hash in format.rb. The reason it was defined in C originally was because it is used in the zone_to_diff method defined in C. However, that can be worked around with some additionally checking in the method. Note that Date::ZONES is no longer defined, only Date::Format::ZONES.
Thanks to clifton for reporting this issue.
Similar as previous change made for Date methods.
In most cases, this is solved by using rb_obj_class(self) instead of hard coding rhrd_class. This does require an API change for rhrd__from_hash, which now takes the class as the first argument.
Previously, Date was hard coded in a few places, so that if you did Class.new(Date).new + 1, you got an instance of Date back, instead of an instance of the subclass. This adds specs for many cases to ensure that the correct class is used. In some cases, these specs pass without code changes, in others the following commit is required. Problem pointed out by aquasync (ruby-ole gem author) as a comment on issue #15.
If it is hard coded, you know it will fit in a Fixnum, so INT2FIX is safe. Many other places in the library LONG2NUM is used where INT2FIX may also work, but I'd have to check each case to be sure.
In certain cases, `home_run --install` or `home_run command` is necessary on 1.9. Projects like Bundler that manipulate the load path and load things in a certain order may break when used with home_run unless you use one of the above. Add a special note about Rails 3, in order to help some users that need to use "require 'home_run'".
Previously, it had the 1.8 behavior of returning the fraction of the second as a fraction of the day, even on 1.9. This increases compatibility with the 1.9 stdlib. This also adds a spec for the :sec_fraction entry of Date._parse, though that is the fraction of the second on both 1.8 and 1.9.