From: Arturo Garcia <arturo.g.arturo@...>
Date: 2010-11-28T20:50:46+09:00
Subject: [ruby-core:33448] Re: [Ruby 1.9-Feature#4068] Replace current standard Date/DateTime library with home_run

On Saturday 27 November 2010 14:48:52 Yukihiro Matsumoto wrote:
> Hi,
> 
> In message "Re: [ruby-core:33420] [Ruby 1.9-Feature#4068] Replace current
> standard Date/DateTime library with home_run"
> 
>     on Sat, 27 Nov 2010 17:15:20 +0900, tadayoshi funaba <redmine@ruby-
lang.org> writes:
> |i'm sorry.
> |i have to say no.
> |bacause, stolen_base gives better results.
I saw the presentation for home_run and I would give a no for its 
inclusion in core, mainly for two things:
1. Is a reimplementation in C (I think we have bad performance because of the 
approach to the problem).

2. It reimplements the following, which I don't think is right:
* (Date.today - 0.5).class ==> Date
?I have doubts about how can i substract half from a day and get a Date, and 
what was the time anyway? and alike.  A date is a point in a calendar, not a 
point in time (for me, at least).

3. Date.gregorian? / england? / julian? etc.... ==>
( I would expect a GregorianDate, EnglandDate, JulianDate, etc.... )
This would make creating dates a snap, no need to implement a date by storing 
an astronomical date.  Same as home_run, in ruby.
GregorianDate.superclass => Date
... or ... if we all user Gregorian calendar
Date.superclass => BaseDate
EnglandDate.superclass => BaseDate

> 
> Well, define "better" here.  You've said stolen_base (DateTime based
> on Time) is "better".  What does it mean?  Better precision?  Better
> performance?  Or Both?
> 
> I have a few questions for the community.
> 
>  * If we have to pick one, which we should choose?  Performance?
>    Precision?
>  * Is there any possibility to achieve both performance and precision
>    at the same time?  Or stolen_base has already fast enough?  Without
>    sacrificing precision?  Any benchmark?
> 
> 							matz.
Me, assurance and mantainability, then performance, then precision.  I develop 
commercial applications.

I agree in approach with Jeremy's code (Date is not a time), but the 
API/approach is still not right IMO.