Converting between Time and DateTime

ruby-talk
21

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.

Kirk Haines

···

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?

22

Lloyd Zusman wrote:

Daniel Schierbeck <daniel.schierbeck@gmail.com> writes:

Lloyd Zusman wrote:

Daniel Schierbeck <daniel.schierbeck@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:

  some_time_method(Time.from_datetime(DateTime.new(...)))

Got it. Thanks!

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. :slight_smile:

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.

Cheers,
Daniel

23

Sounds a bit to me like the difference between Fixnum and Bignum...

Sam

···

On 11/15/05, Kirk Haines <khaines@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.

24

Daniel Schierbeck <daniel.schierbeck@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. :slight_smile:

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
  grady@xcf.berkeley.edu
"Bobby, if you weren't my son, I'd hug you."

25

Sounds a bit to me like the difference between Fixnum and Bignum...

Except that those convert to the one you want automatically, and have
a common superclass (Integer), and just generally play together
nicely.

I *wish* Time and DateTime worked more like Fixnum and Bignum.

Chris

26

Chris Pine wrote:

Sounds a bit to me like the difference between Fixnum and Bignum...

Except that those convert to the one you want automatically, and have
a common superclass (Integer), and just generally play together
nicely.

I *wish* Time and DateTime worked more like Fixnum and Bignum.

Chris

What kind of change would you suggest?

Cheers,
Daniel

27

The analagous behavior would be for every Time method that could have a date
out of range check its inputs, and if that is going to occur, it switched
over to DateTime. However, within the library, that poses some issues.

First, it means lots of value checks on many methods, which is additional
overhead. It also means that in order for this to be relatively transparent,
implementations of a plethora of Time methods, like gm and local and others,
for DateTime. Then, though, does one take the mountain of methods unique to
Date/DateTime and make versions of them in Time? It seems like an awful lot
of code and overhead added to the system libraries for something that's
pretty easy to detect and handle oneself in cases where it is needed, IMHO.

The internal and external aspects of the two classes are so different that I
think it's dangerous to have any built-in casting from one to the other in
the standard library.

I think that there should be some convenience methods, as we have discussed,
to go to and from the three classes (Date, DateTime, and Time), though. One
should not have to reinvent that wheel.

Kirk Haines

···

On Tuesday 15 November 2005 6:52 am, Daniel Schierbeck wrote:

> I *wish* Time and DateTime worked more like Fixnum and Bignum.
>
> Chris

What kind of change would you suggest?

28

Daniel Schierbeck wrote:

Chris Pine wrote:

I *wish* Time and DateTime worked more like Fixnum and Bignum.

What kind of change would you suggest?

I'd like classes like DBI that use Time to (through some trick
like integer->bignum) allow dates 200 years in the future.

Today, that's not the case, and selecting fields representing
a 200-year-lease throws an error when done through DBI.

irb(main):028:0> dbh.select_all("select begin_date,end_date from leases")
ArgumentError: time out of range
         from /usr/lib/ruby/site_ruby/1.8/dbi/sql.rb:60:in `gm'
         from /usr/lib/ruby/site_ruby/1.8/dbi/sql.rb:60:in `as_timestamp'
         from /usr/lib/ruby/site_ruby/1.8/DBD/Pg/Pg.rb:777:in `as_timestamp'
# end date is in 2204.

I'd like to see a Time with an out-of-range year automatically
produce a 'BigTime' class in exactly the same way that an out
of range integer produces a Bignum. Whether this is the same
as DateTime or not doesn't matter much to me. Being able to
use a realistic range of dates in DBI does.

29

Kirk Haines wrote:

I *wish* Time and DateTime worked more like Fixnum and Bignum.

Chris

What kind of change would you suggest?

The analagous behavior would be for every Time method that could have a date out of range check its inputs, and if that is going to occur, it switched over to DateTime. However, within the library, that poses some issues.

First, it means lots of value checks on many methods, which is additional overhead. It also means that in order for this to be relatively transparent, implementations of a plethora of Time methods, like gm and local and others, for DateTime. Then, though, does one take the mountain of methods unique to Date/DateTime and make versions of them in Time? It seems like an awful lot of code and overhead added to the system libraries for something that's pretty easy to detect and handle oneself in cases where it is needed, IMHO.

The internal and external aspects of the two classes are so different that I think it's dangerous to have any built-in casting from one to the other in the standard library.

I think that there should be some convenience methods, as we have discussed, to go to and from the three classes (Date, DateTime, and Time), though. One should not have to reinvent that wheel.

Kirk Haines

I agree. Though I think the very it's odd that Time and DateTime essentially do the same thing (they both represent a date and a time).

This hierarchy would be clearer to me

Time - e.g. 13:05:23 or 5:43 PM
Date - e.g. June 5 1978 A.C. or August 2 430 B.C.
   DateTime - e.g. 5:43 PM, June 5 1978 A.C.

This would basically make a Time instance represent a time of day, and not also a date.

   dt = DateTime.now
   dt.date # returns a Date object
   dt.time # returns a Time object

There could also be a TimeDuration, which represent, well, a duration of time, e.g. 134 hours, 34 minutes and 11 seconds.

just my $ 5 * 10^-2
Daniel

···

On Tuesday 15 November 2005 6:52 am, Daniel Schierbeck wrote:

30

In article <437B3393.9020708@cheapcomplexdevices.com>,
  Ron M <rm_rails@cheapcomplexdevices.com> writes:

I'd like to see a Time with an out-of-range year automatically
produce a 'BigTime' class in exactly the same way that an out
of range integer produces a Bignum. Whether this is the same
as DateTime or not doesn't matter much to me. Being able to
use a realistic range of dates in DBI does.

I think it is hard to do.

Time class needs timezone information provided by OS. But
OS doesn't provides the information for out-of-range year.

So currently I hope 64bit time_t in 64bit OS will be popular.
Since Ruby supports 64bit time_t, Time class works with much
more future on such OS.

···

--
Tanaka Akira

31

That's a DBI problem, though. DBI should use a class appropriate for the
input, and IMHO, should probably default to DateTime instead of Time, though
that's not really a backwards compatible change. The next best thing is for
DBI to pay attention to the inputs, and use DateTime in cases where the
inputs are out of range for Time.

I can provide you with a patch to enable that. Maybe today.

Kirk Haines

···

On Wednesday 16 November 2005 6:22 am, Ron M wrote:

Daniel Schierbeck wrote:
> Chris Pine wrote:
>> I *wish* Time and DateTime worked more like Fixnum and Bignum.
>
> What kind of change would you suggest?

I'd like classes like DBI that use Time to (through some trick
like integer->bignum) allow dates 200 years in the future.

Today, that's not the case, and selecting fields representing
a 200-year-lease throws an error when done through DBI.