=begin
I ran switch_hitter against home_run's test suites. Most of the failures are due to differences between home_run and the standard library. There are a few failures that I think should be addressed in switch_hitter:
Operator methods such as >>, <<, +, and - and methods such as next_day and prev_day should return instances that are the same class of the receiver. This could be complicated as subclasses are generally going to subclass Date and DateTime instead of Date::Light and DateTime::Light. I think it's fair to return a Date::Light for a Date or DateTime::Light for a DateTime, but if the receiver is an instance of a subclass of Date or DateTime, the operator method should return an instance the same subclass.
Class methods such as civil, new, commercial, ordinal, and jd should return instances of the class. Similar to 1), Date.new can return Date or Date::Light, but a subclass of Date should return an instance of that subclass.
Strings returned by Date or DateTime methods should use US-ASCII encoding by default, or the default internal encoding if set.
Date parsing methods such as parse, strptime, httpdate, iso8601, etc. are broken (but the DateTime versions are not).
ruby-head :001 > Date.parse '1/1/2011'
ArgumentError: cannot create
from /home/jeremy/.rvm/rubies/ruby-head/lib/ruby/1.9.1/date.rb:803:in new_l!' from /home/jeremy/.rvm/rubies/ruby-head/lib/ruby/1.9.1/date.rb:803:in new!'
from /home/jeremy/.rvm/rubies/ruby-head/lib/ruby/1.9.1/date.rb:1081:in new_by_frags' from /home/jeremy/.rvm/rubies/ruby-head/lib/ruby/1.9.1/date.rb:1123:in parse'
from (irb):1
from /home/jeremy/.rvm/rubies/ruby-head/bin/irb:16:in `'
Related to 1) is that with switch_hitter's design, subclasses of Date and DateTime are not going to have optimized performance. A user would have to subclass Date::Light or DateTime::Light if they wanted their subclass to have optimized performance. I don't really see a way around this without having some Date objects use internal type T_DATA and other Date objects use internal type T_OBJECT, and having a ruby class whose objects can differ in internal type is probably not a good idea.
=end