From: Rick DeNatale Date: 2009-06-26T08:50:22+09:00 Subject: [ruby-core:24041] Re: [ANN] meeting log of RubyDeveloperKaigi20090622 On Thu, Jun 25, 2009 at 6:20 PM, Yukihiro Matsumoto wrote: > Hi, > > In message "Re: [ruby-core:23995] Re: [ANN] meeting log of RubyDeveloperKaigi20090622" > � �on Wed, 24 Jun 2009 06:19:42 +0900, Jeremy Kemper writes: > > |Since Time is no longer bound by epoch and supports timezones, is there > |future need for DateTime? Could it be reimplemented in terms of Time? > > Date and DateTime has more advanced calendar features based of Julian > date, so they are still needed and the implementation must be > independent from Time. �But casual usage of DateTime will be replaced > by Time gradually. Hi Matz. Would it make sense to consider making DateTime a subclass of Time rather than Date with the new implementation of Time? The current DateTime implementation is *really* slow due to all of the rational arithmetic involved. In my icalendar gem (RiCal) I was using DateTime to do computations for recurring events, and by far the biggest consumer of cpu cycles was the reduction of rationals. I finally implemented a FastDateTime class for internal use only in the gem. Looking at the new code it looks like it goes to the extent of using separate ints for year, month, day, hour, min, sec and NOT a rational, is that right? -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale