Issue #4068 has been updated by Jeremy Evans. The reason for the difference in Tadayoshi's first example is because home_run has nanosecond level resolution. The reason for the difference in Tadayoshi's second example is because home_run doesn't implement the undocumented strftime modifier options and because it stores the timezone offset in minutes. The second example is easy to fix by falling back to the current date strftime code if one of the undocumented strftime modifier options is used, and by changing home_run to store the offset in seconds (or milliseconds) instead of minutes. The first example is basically an inherent limitation in the design. However, it's one that I think most ruby programmers are willing to accept, as repeatably adding small amounts to DateTime objects is uncommon. I have no problem with using stolen_base instead of home_run, at least for DateTime. I think one of the fundamental problems with the standard library is that Date objects are stored as DateTimes at midnight UTC. I think Date objects are fundamentally distinct from DateTimes, and that a Date object should store no time related data. The problem with Date objects storing time related data is shown in my RubyConf presentation: http://jeremyevans-pres.heroku.com/rc2010_presentation/img40.html http://jeremyevans-pres.heroku.com/rc2010_presentation/img46.html Maybe stolen base could be implemented for DateTime, and home_run used as the basis for Date? I rarely use DateTime, my main focus with home_run was the performance of Date, with DateTime only added for compatibility. This hopefully wouldn't be difficult, as home_run already stores Date objects differently than it stores DateTime objects. Tadayoshi, do you have any problem with how home_run implements Date (not DateTime)? If there are issues with how home_run implements Date that can't be resolved, or if using home_run for Date and stolen_base for DateTime is considered too complex, I support stolen_base replacing the current standard Date/DateTime library. ---------------------------------------- http://redmine.ruby-lang.org/issues/show/4068 ---------------------------------------- http://redmine.ruby-lang.org