On Sun, 13 Nov 2005, Lloyd Zusman wrote: > What is the recommended method for converting between Time objects and > those of type DateTime?
OK, let me try again.
irb(main):068:0> t = Time.now => Sat Nov 12 13:33:08 EST 2005 irb(main):069:0> d = DateTime.parse(t.iso8601) => #<DateTime: 52999645097/21600,-5/24,2299161> irb(main):070:0> d.strftime("%c") => "Sat Nov 12 13:33:08 2005" irb(main):071:0> Time.parse(d.strftime("%c")) => Sat Nov 12 13:33:08 EST 2005
'parse' seems to be a good bet in both directions.
>> What is the recommended method for converting between Time objects and >> those of type DateTime?
> OK, let me try again.
> irb(main):068:0> t = Time.now > => Sat Nov 12 13:33:08 EST 2005 > irb(main):069:0> d = DateTime.parse(t.iso8601) > => #<DateTime: 52999645097/21600,-5/24,2299161> > irb(main):070:0> d.strftime("%c") > => "Sat Nov 12 13:33:08 2005" > irb(main):071:0> Time.parse(d.strftime("%c")) > => Sat Nov 12 13:33:08 EST 2005
> 'parse' seems to be a good bet in both directions.
Yes, I thought of these, but they involve converting to and from an intermediate String object. The ones I suggested in my original message are more direct ... although they each require six subsidiary method calls.
If I get some extra time, I'll benchmark my versions against these intermediate-String versions. But no matter which is faster, wouldn't it ultimately be better if we had conversion methods built in to the standard classes? Even if we don't unify Time with DateTime, these extra contstructors would be a nice convenience.
Daniel Schierbeck <daniel.schierb...@gmail.com> writes: > [ ... ]
> I think this would be more Rubyish:
> class DateTime > def to_time > Time.mktime(year, mon, day, hour, min, sec) > end > end
> class Time > def to_datetime > DateTime.civil(year, mon, day, hour, min, sec) > end > end
> I haven't tested it, but it should work.
Thanks. Is this considered more ruby-ish because of the non-camel-case of the method names? ... or because of the to_* methods instead of the from* constructors? ... or both?
On Saturday 12 November 2005 11:26 am, David A. Black wrote:
> (Could we get all the time/date stuff unified and loaded by default? > Is that too much overhead?)
I don't know if that is practical. Time and Date/DateTime use two entirely different mechanisms for keeping track of the passage of time. Time utilizes seconds since the start of 1970 -- standard Unix time tracking.
Date/DateTime uses keeps tracks of days and fractions of days using Rational, and it's start of time is about the start of the year in 4712 B.C.
They are quite different, and while one should not have to write one's own code to convert from one to another -- all three classes should be patched to allow each conversion from one to another -- they should stay separate.
On Saturday 12 November 2005 11:35 am, David A. Black wrote:
> OK, let me try again.
> irb(main):068:0> t = Time.now > => Sat Nov 12 13:33:08 EST 2005 > irb(main):069:0> d = DateTime.parse(t.iso8601) > => #<DateTime: 52999645097/21600,-5/24,2299161> > irb(main):070:0> d.strftime("%c") > => "Sat Nov 12 13:33:08 2005" > irb(main):071:0> Time.parse(d.strftime("%c")) > => Sat Nov 12 13:33:08 EST 2005
> 'parse' seems to be a good bet in both directions.
It works in both directions because the underlying 'parse' is the same one. :)
They all use the same the Date#_parse method defined in date/format.rb.
Using this is going to be much slower than just doing conversions with the numerical values and constructor methods that the classes provide.
On Mon, 14 Nov 2005, Kirk Haines wrote: > On Saturday 12 November 2005 11:26 am, David A. Black wrote:
>> (Could we get all the time/date stuff unified and loaded by default? >> Is that too much overhead?)
> I don't know if that is practical. Time and Date/DateTime use two entirely > different mechanisms for keeping track of the passage of time. Time utilizes > seconds since the start of 1970 -- standard Unix time tracking.
> Date/DateTime uses keeps tracks of days and fractions of days using Rational, > and it's start of time is about the start of the year in 4712 B.C.
> They are quite different, and while one should not have to write one's own > code to convert from one to another -- all three classes should be patched to > allow each conversion from one to another -- they should stay separate.
I guess what I'm thinking of mostly is default loading. It seems a little odd to see this:
irb(main):002:0> Time => Time irb(main):003:0> require 'time' => true
and, in general, to have to know what you can do before you load things and what you can only do after. Not so much reducing the three classes to one, then, but streamlining the way it all works.
Kirk Haines <khai...@enigo.com> writes: > On Saturday 12 November 2005 10:54 am, Lloyd Zusman wrote:
>> Is there any reason for why we can't have similar methods as part of the >> official DateTime and Time classes?
>> Or is there already some sort of mechanism for this that I have >> overlooked?
> You have not overlooked anything.
Oh well ... (sigh)
And thanks.
In your methods below, I see "rescue" without a formal "begin/end" block. I've never seen that construct before. I'm guessing that single line statements don't need begin/end, correct?
L> In your methods below, I see "rescue" without a formal "begin/end" L> block. I've never seen that construct before. I'm guessing that single L> line statements don't need begin/end, correct?
no, no : this is a difference 1.4 and 1.6. Since 1.6 you can write
def aa # any lines rescue XXX # any lines rescue YYY # any lines # ... else # any lines ensure # any lines end
this is only with 1.6.3 that it work also with singleton methods.
On Mon, 14 Nov 2005, Lloyd Zusman wrote: > In your methods below, I see "rescue" without a formal "begin/end" > block. I've never seen that construct before. I'm guessing that single > line statements don't need begin/end, correct?
Method defs provide an implicit 'begin', so you can put a rescue clause in them without adding a 'begin'.
Lloyd Zusman wrote: > Daniel Schierbeck <daniel.schierb...@gmail.com> writes:
>> [ ... ]
>> I think this would be more Rubyish:
>> class DateTime >> def to_time >> Time.mktime(year, mon, day, hour, min, sec) >> end >> end
>> class Time >> def to_datetime >> DateTime.civil(year, mon, day, hour, min, sec) >> end >> end
>> I haven't tested it, but it should work.
> Thanks. Is this considered more ruby-ish because of the non-camel-case > of the method names? ... or because of the to_* methods instead of the > from* constructors? ... or both?
Both. It also allows you to do something like this:
def some_time_method(time) time = time.to_time # now we know we have a Time object end
some_time_method(DateTime.new(...))
That way you can use a DateTime object instead of a Time object and have it automatically converted. Otherwise, you'd have to do this:
Daniel Schierbeck <daniel.schierb...@gmail.com> writes: > Lloyd Zusman wrote: >> Daniel Schierbeck <daniel.schierb...@gmail.com> writes:
>>> [ ... ]
>>> I think this would be more Rubyish:
>>> class DateTime >>> def to_time >>> Time.mktime(year, mon, day, hour, min, sec) >>> end >>> end
>>> class Time >>> def to_datetime >>> DateTime.civil(year, mon, day, hour, min, sec) >>> end >>> end
>>> I haven't tested it, but it should work. >> Thanks. Is this considered more ruby-ish because of the non-camel-case >> of the method names? ... or because of the to_* methods instead of the >> from* constructors? ... or both?
> Both. It also allows you to do something like this:
> def some_time_method(time) > time = time.to_time # now we know we have a Time object > end
> some_time_method(DateTime.new(...))
> That way you can use a DateTime object instead of a Time object and have > it automatically converted. Otherwise, you'd have to do this:
So now, all we need is to have a few to_* conversion methods added to the standard Time, DateTime, and Date classes so that we all don't have to keep re-inventing this. :)
> L> In your methods below, I see "rescue" without a formal "begin/end" > L> block. I've never seen that construct before. I'm guessing that single > L> line statements don't need begin/end, correct?
> no, no : this is a difference 1.4 and 1.6. Since 1.6 you can write
>> In your methods below, I see "rescue" without a formal "begin/end" >> block. I've never seen that construct before. I'm guessing that single >> line statements don't need begin/end, correct?
> Method defs provide an implicit 'begin', so you can put a rescue > clause in them without adding a 'begin'.
I never realized this. I guess I overlooked that part of the docs. This will allow me to remove a few begin/end constructs from some of the short methods I've written.
Lloyd Zusman wrote: > Daniel Schierbeck <daniel.schierb...@gmail.com> writes:
>> Lloyd Zusman wrote: >>> Daniel Schierbeck <daniel.schierb...@gmail.com> writes:
>>>> [ ... ]
>>>> I think this would be more Rubyish:
>>>> class DateTime >>>> def to_time >>>> Time.mktime(year, mon, day, hour, min, sec) >>>> end >>>> end
>>>> class Time >>>> def to_datetime >>>> DateTime.civil(year, mon, day, hour, min, sec) >>>> end >>>> end
>>>> I haven't tested it, but it should work. >>> Thanks. Is this considered more ruby-ish because of the non-camel-case >>> of the method names? ... or because of the to_* methods instead of the >>> from* constructors? ... or both?
>> Both. It also allows you to do something like this:
>> def some_time_method(time) >> time = time.to_time # now we know we have a Time object >> end
>> some_time_method(DateTime.new(...))
>> That way you can use a DateTime object instead of a Time object and have >> it automatically converted. Otherwise, you'd have to do this:
> So now, all we need is to have a few to_* conversion methods added to > the standard Time, DateTime, and Date classes so that we all don't have > to keep re-inventing this. :)
Yeah, but only if there's a strong enough sentiment in the community. No reason to add to the standard library unless the functionality is really needed.
Daniel Schierbeck <daniel.schierb...@gmail.com> writes: >Lloyd Zusman wrote: >> So now, all we need is to have a few to_* conversion methods added to >> the standard Time, DateTime, and Date classes so that we all don't have >> to keep re-inventing this. :)
>Yeah, but only if there's a strong enough sentiment in the community. No >reason to add to the standard library unless the functionality is really >needed.
Well, as it turns out, last week I spent about an hour looking for these conversion functions (using ri, the pickaxe book, etc.), before realizing they weren't part of the standard library and writing them myself. Another reason to add to the standard library is if something is so natural that is confusing to _not_ find it there. -- Steven gr...@xcf.berkeley.edu "Bobby, if you weren't my son, I'd hug you."
On Monday 14 November 2005 11:12 am, Adam Sanderson wrote:
> Is there any reason to choose one over the other? At least for post > 1970 dates? I've always found Time's API a little easier to use.
> Anyone have thoughts on when one would want to use DateTime vs Time?
The range is one difference. If you want to represent 376 AD, you can't use Time.
Time will be faster, since DateTime uses Rational for everything. DateTime's units are days and fractions of days. That might make a difference to you, or it might not. If you are doing a lot of date conversion or date math, you might find DateTime easier to use.
Hmmm. It's a good question, and I don't have as good an answer as you want, probably.
Personally, I use Time unless I am dealing with date ranges that go beyond what Time handles, as a general rule.
On 11/15/05, Kirk Haines <khai...@enigo.com> wrote:
> On Monday 14 November 2005 11:12 am, Adam Sanderson wrote: > > Is there any reason to choose one over the other? At least for post > > 1970 dates? I've always found Time's API a little easier to use.
> > Anyone have thoughts on when one would want to use DateTime vs Time?
> The range is one difference. If you want to represent 376 AD, you can't use > Time.
> Time will be faster, since DateTime uses Rational for everything. DateTime's > units are days and fractions of days. That might make a difference to you, > or it might not. If you are doing a lot of date conversion or date math, you > might find DateTime easier to use.
Sounds a bit to me like the difference between Fixnum and Bignum...
|
