Florian Frank
8/22/2007 11:43:00 PM
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