Re: hires DateTime-from_epoch( epoch = ... ) values
On Mon, Aug 08, 2005 at 10:45:19AM -0500, Dave Rolsky wrote: On Mon, 8 Aug 2005, John Siracusa wrote: On 8/8/05, Dave Rolsky [EMAIL PROTECTED] wrote: Does anyone object to adding Math::BigFloat as a prereq? What are the performance/memory implications? I don't object to the prereq, but I would like to know if we're in for any new speed/bloat issues. (I only really care about per-object overhead, not the cost of loading Math::BigFloat itself.) If I read the patch directly, we never store the bigfloat object, we just use it to make sure that nanoseconds has the right value. That's correct. A single Math::BigFloat object is used as an intermediate value, to hold the hires epoch 'string', which is then immediately discarded after seperating the integer and fractional values. It shouldn't have much impact on memory unless Math::BigFloat has leaks. ;) Cheers, -J -- pgpEitMgczkpC.pgp Description: PGP signature
[RFC] Data::ICal::DateTime
Jesse Vincent and David Glasser recently released v0.02 of Data::ICal
which included my patches to allow it to parse .ics files. This allowed
me to whip up Data::ICal::DateTime which makes it easy (well, easier at
least) to deal with iCalendars and DateTime.
The long and short of it is that that can do
my $cal = Data::ICal-new('foo.ics');
my $span = DateTime::Span-from_datetimes(start=$d1, end =$d2);
# return all events, including instances of recurring events
my @events = $cal-events($span);
# return all events, split multi-day events up
my @events = $cal-events($span, 'day');
Obviously, $span can also be a Set or SpanSet.
Which is all lovely and groovy but, since releasing, I've had the
feeling that my TimeZone support is bogus - not least because if I do
$span-set_time_zone('Europe/London');
then I can wildly different results even though all the events in the
calendar have that TZID
I'm pretty much an idiot when it comes to these things - this module was
cobbled together using the finest cargo cult and suck-it-and-see
technology so I'd appreciate some feed back and pointers on where I
might be going wrong.
Thanks,
Simon
--
rorshach and prozac and everything's groovy
Re: hires DateTime-from_epoch( epoch = ... ) values
On Mon, Aug 08, 2005 at 09:02:06AM -1000, Joshua Hoblitt wrote: On Mon, Aug 08, 2005 at 10:45:19AM -0500, Dave Rolsky wrote: On Mon, 8 Aug 2005, John Siracusa wrote: On 8/8/05, Dave Rolsky [EMAIL PROTECTED] wrote: Does anyone object to adding Math::BigFloat as a prereq? What are the performance/memory implications? I don't object to the prereq, but I would like to know if we're in for any new speed/bloat issues. (I only really care about per-object overhead, not the cost of loading Math::BigFloat itself.) If I read the patch directly, we never store the bigfloat object, we just use it to make sure that nanoseconds has the right value. That's correct. A single Math::BigFloat object is used as an intermediate value, to hold the hires epoch 'string', which is then immediately discarded after seperating the integer and fractional values. It shouldn't have much impact on memory unless Math::BigFloat has leaks. ;) On second thought, would we be better off simplifying DateTime::from_epoch to only handle integer values and move all the floating point complexity into DateTime::HiRes? That would be optimizing the common case. Cheers, -J -- pgpivzyAm7UOQ.pgp Description: PGP signature
