Converting between Time and DateTime

[Steven Grady From:]

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.

 

[Adam Sanderson]

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?
.adam sanderson

 

[Kirk Haines]

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.


Kirk Haines

 

[Sam Gentle]

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. DateTi= me's
units are days and fractions of days. That might make a difference to yo= u,
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...

Sam

 

[Chris Pine]

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

 

[kzm]

hey list...

i need to unsubscribe for a while.. i am not sure it works here,
can anybody tell me please?

thanx

\n

 

[Daniel Schierbeck]

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

 

[Kirk Haines]

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

 

[Daniel Schierbeck]

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

 

[Ron M]

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.

 

[Tanaka Akira]

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.

 

[Kirk Haines]

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.

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