On Wed, 6 Aug 2003, Dave Rolsky wrote:
I just checked this in, but I'm not sure if it's much faster. It'd be
good if someone who knows more about about C could look at the
implementation and see if there's anything they can think of to improve
it. Also, I should probably change the
Dave Rolsky wrote:
Ok, I did some benchmarks and it looks like date math involving leap
seconds (basically an DateTime object where the time zone is _not_
floating) has sped up about 10% or so, which is definitely a good thing.
How about moving the pure-Perl DT::LeapSecond to DateTime.pm/ ?
How about moving the pure-Perl DT::LeapSecond to DateTime.pm/ ?
Seems like a good idea. Do you want to do it or should I?
I'd like to keep it separated. I believe it maybe useful outside the context of DT.
-J
--
Dave Rolsky wrote:
On Wed, 6 Aug 2003, Flavio S. Glock wrote:
Dave Rolsky wrote:
Ok, I did some benchmarks and it looks like date math involving leap
seconds (basically an DateTime object where the time zone is _not_
floating) has sped up about 10% or so, which is definitely a
I suspect updates to it will be quite infrequent, though. Other than new
leap seconds, why else would it change?
I hadn't read ahead in my email. I was concerned about the functionality being
folding into the DT namespace and the DT::Leapsecond interface disappearing. That
didn't happen so
On Wed, 6 Aug 2003, Joshua Hoblitt wrote:
How about moving the pure-Perl DT::LeapSecond to DateTime.pm/ ?
Seems like a good idea. Do you want to do it or should I?
I'd like to keep it separated. I believe it maybe useful outside the context of DT.
I suspect updates to it will be quite
On Wed, 6 Aug 2003, Flavio S. Glock wrote:
Dave Rolsky wrote:
Ok, I did some benchmarks and it looks like date math involving leap
seconds (basically an DateTime object where the time zone is _not_
floating) has sped up about 10% or so, which is definitely a good thing.
How about
