Project

General

Profile

Actions

Bug #6753

closed

Comparing Date::Infinity with Date/DateTime

Added by herwinw (Herwin Quarantainenet) over 12 years ago. Updated over 12 years ago.

Status:
Rejected
Target version:
ruby -v:
ruby 1.9.3p0 (2011-10-30 revision 33570) [i686-linux]
Backport:
[ruby-core:46557]

Description

Depending on the order you use for comparing, this works or throws an error. A snippet from IRB

irb(main):001:0> require 'date'
=> true
irb(main):002:0> DateTime.now < Date::Infinity.new
=> true
irb(main):003:0> Date::Infinity.new > DateTime.now
ArgumentError: comparison of Date::Infinity with DateTime failed

The same thing happens when using Date instead of DateTime.

The problem arises in Date::Infinity#<=>(other). This method checks if the other is a Date::Infinity (it is not) or a Numeric (it is not). It then falls back to the generic code, which calls other.coerce. Since both instances of DateTime and Date don't have a coerce method this fails.

I've fixed the problem here by adding this line to Date::Infinity#<=>(other)

when DateTime, Date; return d

This is not optimal, because when you'll try to compare an instance created with Date::Infinity.new(0), it will always return 0 when comparing with a Date(Time), which means any Date(Time) will be equal to Date::Infinity.new(0). Then again, I don't see the use case where you would initialize the Date::Infinity with a value of 0, and the same problem happens when you're comparing it with a Numeric.

irb(main):006:0> Date::Infinity.new(0) == 4
=> true

I'm not really familiar with the background of the coerce method, but relying on the coerce of a given parameter seems a little bit weird to me. There is no check on the type of the parameter (except it is not Date::Infinity and not numeric) which means the coerce method can be anything (if it exists).

Actions

Also available in: Atom PDF

Like0
Like0Like0