Issue #6547 has been updated by lmc (Luke Mcildoon).

File date_initialize_patch.diff added

I disagree, I believe this is a bug since it results in extremely surprising behaviour, and no other stdlib classes do this (even String.new calls initialize).
I've fixed this myself by adding calls to rb_obj_call_init in date_core.c, and benchmarked it over 1,000,000 calls.

Without initialize: 0.51281475 sec
With initialize: 0.84253075 sec

While I agree there is a performance decrease, I think that the current behaviour is arguably "cheating", especially considering core classes that are used far more often than Date/DateTime behave correctly.
----------------------------------------
Bug #6547: DateTime.new does not call #initialize
https://bugs.ruby-lang.org/issues/6547#change-27517

Author: lmc (Luke Mcildoon)
Status: Rejected
Priority: Low
Assignee: tadf (tadayoshi funaba)
Category: ext
Target version: 
ruby -v: ruby 1.9.3p194 (2012-04-20 revision 35410) [i686-linux]


Classes that extend DateTime don't appear to have their "initialize" instance method called from "new".

To reproduce:
irb(main):001:0> [RUBY_VERSION,RUBY_PLATFORM]
=> ["1.9.3", "i686-linux"]
irb(main):002:0> require "date"
=> true
irb(main):003:0> class DateTimeExtension < DateTime
irb(main):004:1> def initialize(*args)
irb(main):005:2> raise "DateTimeExtension#initialize called"
irb(main):006:2> end
irb(main):007:1> end
=> nil
irb(main):008:0> DateTimeExtension.new
=> #<DateTimeExtension: -4712-01-01T00:00:00+00:00 ((0j,0s,0n),+0s,2299161j)> # no exception raised

I expected calling "DateTimeExtension.new" to raise the exception from inside "initialize".



-- 
http://bugs.ruby-lang.org/