Comparing `Time` object with an integer doesn't throw an error about rails HOT 2 OPEN

I tried to follow the method chain for Time#<=>, since it's used for >= comparisons. In Rails, that method is defined as #compare_with_coercion:

The integer value on the right side of the comparison isn't Time-ish, so the Time object on the left side gets converted to a DateTime and then compared to the integer value. DateTime#<=> checks if the object on the right side responds to #to_datetime and goes up the inheritance chain if not (which is the case here):

The super-method in this case is Date#<=>. There's a method in Rails for this, but it ends up calling the native #<=> method for DateTime (which is defined on Date) if the object on the right side isn't a Time:

Here's the twist. While I didn't read through the C code for the native Date#<=>, https://ruby-doc.org/3.2.2/exts/date/Date.html#method-i-3C-3D-3E specifically notes that when comparing to a numeric value, the #ajd method is called on the Date and the resulting value is compared to the numeric value on the right side. That #ajd method is the "astronomical Julian day number"; I wouldn't have been able to tell you what that meant before today, but the important thing is that it's a count of days (since about 6700 years ago) and nowadays is between 2_000_000 and 3_000_000. But the integer on the right side of the comparison came from calling Time#to_i, and that's the number of seconds since January 1, 1970, currently a bit over 1_700_000_000. So you have to subtract a very large number from Time.now.to_i in order for Time.now to compare as greater. And for what it's worth, this also affects DateTime comparisons to integers.

I haven't checked to see how far back this behavior goes.

from rails.

To follow up on this a bit and lend support to the original statement of the issue, I think it makes sense that for any Time instances t1 and t2, if t1 > t2 evaluates to true and t1.to_i > t2.to_i evaluates to true, then t1 > t2.to_i should either evaluate to true or raise an exception. Instead, due to unexpected coercion, t1 > t2.to_i is only true if t2 is on or before 1970-01-29 (the latest day that included a time when the number of seconds since the Unix epoch was less than the astronomical Julian day number) or t1 is very far in the future. All of this goes for DateTime instances as well.

In terms of solving this, I'm not sure whether it makes more sense to fix it in Time or DateTime. Fixing it in DateTime should also address the issue in Time (due to the partial delegation of Time#<=> to DateTime#<=>) but it isn't clear to me what the solution would be for DateTime. I'm assuming that there isn't much interest in making DateTime#<=> coerce the object into Unix time when comparing to a numeric value, since that could cause the method to return a completely different value just by adding Active Support to a project. Alternatively, the DateTime#to_i method in Active Support could be changed to return the astronomical Julian day number instead of Unix time, which would be more conceptually consistent with Ruby. But that method has returned the Unix time in Rails for almost 15 years, and DateTime#to_f has returned a comparable number for even longer. And since Ruby considers DateTime deprecated, maybe it makes sense to just fix the issue in Time and not worry about DateTime?

from rails.