From: "lmc (Luke Mcildoon)" Date: 2012-06-27T17:25:41+09:00 Subject: [ruby-core:45911] [ruby-trunk - Bug #6547] DateTime.new does not call #initialize 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 => # # no exception raised I expected calling "DateTimeExtension.new" to raise the exception from inside "initialize". -- http://bugs.ruby-lang.org/