Bug #15712
closedDateTime#=== should be defined and compare date and time instead of just the date
Description
DateTime#=== is inherited from Date#=== without overwriting the #=== method, this leads to DateTime#=== comparing only dates and ignore the time part.
DateTime.new(2001, 2, 3) === DateTime.new(2001, 2, 3, 12)
=> false
I think this is not the expected behavior but existing code might rely on this.
Date#===: https://ruby-doc.org/stdlib-2.1.9/libdoc/date/rdoc/Date.html#method-i-3D-3D-3D
Source: https://medium.com/@dvandersluis/an-rspec-time-issue-and-its-not-about-timezones-a89bbd167b86
Updated by hsbt (Hiroshi SHIBATA) almost 6 years ago
@localhostdotdev (localhost .dev)
I fixed an issue of our tracker. I deleted 15713-15716.
Updated by nobu (Nobuyoshi Nakada) almost 6 years ago
- Status changed from Open to Feedback
What version of DateTime do you use?
With the trunk I got:
require 'date'
dt1 = DateTime.new(2001, 2, 3)
dt2 = DateTime.new(2001, 2, 3, 12)
p dt1 === dt2 #=> true
p dt1 == dt2 #=> false
Updated by localhostdotdev (localhost .dev) almost 6 years ago
@nobu (Nobuyoshi Nakada) Not sure why I wrote false (maybe I confused === with == in my testing), I'm getting true
on ruby 2.5.3, 2.6.1, 2.6.2 and ruby-head (2.7.0 (same as the one registered in the issue)).
rvm ruby-head do ruby -e 'require "date"; dt1 = DateTime.new(2001, 2, 3); dt2 = DateTime.new(2001, 2, 3, 12); puts "=== #{dt1 === dt2}"; puts "== #{dt1 == dt2 }"; puts RUBY_VERSION'
Updated by matz (Yukihiro Matsumoto) about 4 years ago
I admit it is a bug. But we consider use of DateTime
should be discouraged. So we keep this bug behavior for compatibility's sake.
We are going to describe obsoletion in the document.
Matz.
Updated by jeremyevans0 (Jeremy Evans) about 4 years ago
- Status changed from Feedback to Closed
DateTime deprecation documentation was added to date: https://github.com/ruby/date/commit/58ca6e6a3ee20c72a77266e0f74920b12a06ee9d
Date#===
is describes the current behavior as only considering the date, and uses examples with DateTime
, so I think the situation is fully documented and I'm closing this.