[ruby-core:33450] Re: [Ruby 1.9-Feature#4068] Replace current standard Date/DateTime library with home_run

Hi Matz,

On 27 November 2010 15:48, Yukihiro Matsumoto <[e-mail]> wrote:
| Hi,
|
| 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.

I think the Date class need mainly performance, or - as another way to
say it - a better design.

Time's precision seems good enough, as the further example shows.
I am wondering of the utility of DateTime, so I will not speak about
its precision.

-------

I have a question: What brings DateTime that Time does not have?

From tadayoshi funaba's example,
> p 1000.times.inject(Time.new(2000)) {|s, | s + Rational(1, 259200/(24*3600))}.strftime('%F %T %20N')
"2000-01-01 00:05:33 33333333333333333333"

From methods view:
> DateTime.instance_methods - Time.instance_methods
Mainly aliases, a notion of different calendars, next_* (prev_*) and
the #<< and #>> operators.
These operators (and prev/next) could of course be implemented for
Time (and I think they should).

> Time.instance_methods - DateTime.instance_methods
A few useful conversions and #round.

They have 10 common methods (if we except the ones of Object)
> [Time.instance_methods(false), DateTime.instance_methods(false)].map {|m| m-Object.instance_methods }.reduce(:&)
=> [:sec, :min, :hour, :zone, :strftime, :to_time, :to_date,
:to_datetime, :xmlschema, :iso8601]

So, unless I am missing something,
  do we even need DateTime, for which reason ?

-------

On 28 November 2010 06:17, Jeremy Evans <[e-mail]> wrote:
| 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

I totally agree mixing the Date class with a notion of time is bad design.
That is the main reason I want to support home_run, for Date.
And because I want a real and efficient Date class, or none.

On 28 November 2010 12:50, Arturo Garcia <[e-mail]> wrote:
| 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).

I would take these as 2 arguments *for* home_run.

I do not understand your opinion about (1). If you think we have bad
performance, a reimplementation in C should be good news.

About adding/subtracting non-Integer from a Date, I think it does not
make sense.
If you plan to have partial days, then you are thinking to some notion of Time.

I think it should even raise an exception when adding a partial day to a Date.
If you have at first a Date, and want to add some time notion,
date.to_time + 0.5
seems an explicit and a good way.

Regards,
B.D.