Hi Sam.
I've cc'd the datetime mailing list so that they can chime in if they want.
I am trying to write a converter for crontab entries into another format
(iCal). Unfortunately I need a limited recurrence set as the output
module does not allow infinite sets. I thought that using the
I am trying to write a converter for crontab
entries into another format
(iCal). Unfortunately I need a limited
recurrence set as the output
module does not allow infinite sets. I thought
that using the %parms or
the %set_parms I would be able to limit the Set
produced using from_cron
On Wed, 6 Apr 2005 [EMAIL PROTECTED] wrote:
Yes - if the set has up to 200 elements (that's an internal hard limit),
DateTime::Format::ICal should do the right thing:
Why the internal hard limit? If people want to use up all their memory,
that's their problem. A warning in the docs is good,
On Wed, 6 Apr 2005 [EMAIL PROTECTED] wrote:
Yes - if the set has up to 200 elements (that's
an internal hard limit),
DateTime::Format::ICal should do the right thing:
Why the internal hard limit? If people want to use
up all their memory,
that's their problem. A warning in the
On Wed, 6 Apr 2005 [EMAIL PROTECTED] wrote:
Yes - if the set has up to 200 elements (that's
an internal hard limit),
[...]
Why the internal hard limit? If people want to
use up all their memory,
that's their problem. A warning in the docs is
good, but just giving up
On Wed, 6 Apr 2005 [EMAIL PROTECTED] wrote:
Why the internal hard limit? If people want to use up all their
memory, that's their problem. A warning in the docs is good, but just
giving up at an arbitrary number just makes the software less useful.
I think this can be fixed - I'll try and make
Dave Rolsky wrote:
One possibility is to simply return undef for
methods that might cause
infinite loops when we don't know for certain they
won't.
Calculating whether or not this can happen is
probably possible in some
cases (defined start end), and in others we can
offer a
