From: Florian Frank <flori@...>
Date: 2007-08-23T08:43:08+09:00
Subject: Re: time class changed in ruby-1.8.6?

Daniel DeLorme wrote:
> You're probably using rails.

No, I am not. Maybe Mr. Ball did. I didn't remember, if there already 
where any of those methods before, but I have implemented my own set of 
to_* methods to convert between the different objects a while ago.  Of 
course there also had to be solutions to convert a DateTime to a Time 
object, if the latter is not valid, e.g. before the epoch, or a Date 
object to a Time object: which time will it show?

It still doesn't make sense to not have any way to convert between the 
three types of objects (short of using #parse/the ugly long 
constructors) or have only a part of them as private methods. And why 
are the objects immutable? And if they have to be immutable, why is it 
so difficult to create a new object from the old, that shows 13:13:13 
instead of 23:13:42 without adding the exact amount of seconds to it or 
use constructors/parse?

> Ruby used to *not* have a Time#to_date 
> method but now it has one which is private. And the to_date helper added 
> by rails is further up the call chain and therefore gets hidden by the 
> private method, so that's what you get. :-/
> 
> Add one of the following in your environment.rb:
>   class Time; public :to_date ;end #use the ruby-1.8.6 version
>   class Time; remove_method :to_date ;end #use the rails version

I think Ruby without Rails should also be able to handle dates and times 
well. When I implemented those methods myself, I wondered if anyone uses 
all these classes at all, because so much was missing to make them 
useful. And if everybody keeps monkey patching the missing methods, it's 
no wonder, that things break, if the standard library changes again.

To create a good API for these timely things seems to be difficult: Java 
for example trys it for the second time: its Calendar API is very, very 
powerful but it still sucks, especially for the simple things.

-- 
Florian Frank