> Ok, this is wack. When I ask the object for "delta_days" or just "days"
> what is it going to give me?
Uhh... the same thing it always has? Maybe I'm missing your point. We're talking
about overloaded operators returning another duration object. Why would that change
the return of methods?
Quoting Dave Rolsky <[EMAIL PROTECTED]>:
> This is hard, since recurrences are implemented as closures/coderefs, and
> there's no way to look at one and figure out what it represents.
Is it feasible, during construction, to leave enough bread crumbs around to
reverse the process?
(I would imagine
On Mon, 30 Jun 2003, Joshua Hoblitt wrote:
> > Why not:
> >
> > $dur1 = new DT::Dur( days => 2 );
> > $dur2 = new DT::Dur( months => 1 );
> > $dur3 = $dur1 - $dur2;
> > $dur3->add( days => 3 );
> >
> > If you add $dur3 to a date, it would add 2 days and
> > subtract a month, then add 3 days again.
On Mon, 30 Jun 2003, Matt Sisk wrote:
> Found the parse_recurrence docs in the CVS, thanks.
>
> However, there's a good reason the format_recurrence method is not
> documented...it doesn't exist.
>
> Are there plans to implement this?
This is hard, since recurrences are implemented as closures/co
> Why not:
>
> $dur1 = new DT::Dur( days => 2 );
> $dur2 = new DT::Dur( months => 1 );
> $dur3 = $dur1 - $dur2;
> $dur3->add( days => 3 );
>
> If you add $dur3 to a date, it would add 2 days and
> subtract a month, then add 3 days again.
>
> This is not too difficult to implement.
> Is it too confu
On Mon, 30 Jun 2003, Matt Sisk wrote:
> > Documented or not, it'll never be intuitive, which makes me think it's a
> > bad idea.
>
> This could be a feature of the problem space rather than implementation. :)
>
> I'd say it's safe to say 99% of non-temporal geeks underestimate the subtle
> complex
Found the parse_recurrence docs in the CVS, thanks.
However, there's a good reason the format_recurrence method is not
documented...it doesn't exist.
Are there plans to implement this?
Thanks,
Matt
They are documented in CVS version.
> Is there some reason the parse/format routines for
recurrences in DT::F::ICal
> are not documented in the POD? Is there anyhing
wrong with these methods or is
> the lack of documentation an oversight?
Is there some reason the parse/format routines for recurrences in DT::F::ICal
are not documented in the POD? Is there anyhing wrong with these methods or is
the lack of documentation an oversight?
Thanks,
Matt
You are right, I will move stuff around for it to be DT:Fiscal:Year
> Documented or not, it'll never be intuitive, which makes me think it's a
> bad idea.
This could be a feature of the problem space rather than implementation. :)
I'd say it's safe to say 99% of non-temporal geeks underestimate the subtle
complexity of the problem..."intuitive" ends up being inco
> [EMAIL PROTECTED]:
> > Why not:
> >
> > $dur1 = new DT::Dur( days => 2 );
> > $dur2 = new DT::Dur( months => 1 );
> > $dur3 = $dur1 - $dur2;
> > $dur3->add( days => 3 );
> >
> > If you add $dur3 to a date, it would add 2 days and
> > subtract a month, then add 3 days again.
>
> I love that thi
On Mon, 30 Jun 2003, Matt Sisk wrote:
> So, yes, the implication is that:
>
> $dur = DT::Dur->new(days => 2, months => -1);
>
> would indeed behave differently than:
>
> $dur = DT::Dur->new(months => -1, days => 2);
>
> So long as the behavior (intrinsic to durations) is well documented I thin
[EMAIL PROTECTED]:
> Why not:
>
> $dur1 = new DT::Dur( days => 2 );
> $dur2 = new DT::Dur( months => 1 );
> $dur3 = $dur1 - $dur2;
> $dur3->add( days => 3 );
>
> If you add $dur3 to a date, it would add 2 days and
> subtract a month, then add 3 days again.
I love that this "does the right thing"
On Tuesday, July 1, 2003 [EMAIL PROTECTED] wrote:
>Why not:
>
>$dur1 = new DT::Dur( days => 2 );
>$dur2 = new DT::Dur( months => 1 );
>$dur3 = $dur1 - $dur2;
>$dur3->add( days => 3 );
>
>If you add $dur3 to a date, it would add 2 days and
>subtract a month, then add 3 days again.
>
>This is not too
Why not:
$dur1 = new DT::Dur( days => 2 );
$dur2 = new DT::Dur( months => 1 );
$dur3 = $dur1 - $dur2;
$dur3->add( days => 3 );
If you add $dur3 to a date, it would add 2 days and
subtract a month, then add 3 days again.
This is not too difficult to implement.
Is it too confusing?
- Flavio S. G
I needed to convert between Date::Manip and DateTime so I wrote a
module to convert the date and duration formats (recurrences may
follow if there is demand, there are some nasty wrinkles though).
Get it from http://www.limey.net/~fiji/perl/
If people see no major problems with this module I wil
Surely there's some coffee shops or net cafes around with wireless and/or jacks?
These days it's generally gratis so long as you buy a coffee every now and then.
(haven't been paying attention, so I'm not sure exactly which city we're talking
about)
Matt
> I'm just starting to panic that I am not going to be able to survive with just a
> P233 notebook with a 56k modem when I am used to a 1.2GHz w/768k DSL. ;~) I've
> got a bunch of programming I want to accomplish next week and I don't want to be
> hampered by poor connectivity...
I'm in the same
On Mon, 30 Jun 2003, Ben Bennett wrote:
> I am totally mystified. I read "If any of the numbers are negative,
> the entire duration is negative." as indicating that the individual
> signs don't matter.
>
> I think the error is on DT::Duration line 52:
> $self->{minutes} = abs( ( $p{hours} * 60
On Mon, 30 Jun 2003, Flavio S. Glock wrote:
> > Well, maybe. Right now the constructor is really simple, which is good.
> > More functionality is nice, but so is simplicity.
>
> use DateTime;
> my $dt = DateTime->now;
> my $dur = sub { $_[0]->add( months => 3 )->subtract( hours => 3 ) };
> print
On Mon, Jun 30, 2003 at 12:20:43PM -0500, Dave Rolsky wrote:
> > 2) Having a way to construct this directly would be nice being able
> > to make a duration that you can not directly construct seems odd.
>
> Well, maybe. Right now the constructor is really simple, which is good.
> More functi
Dave Rolsky wrote:
>
> On Mon, 30 Jun 2003, Ben Bennett wrote:
>
> > The nits:
> > 1) The following doesn't work because add_duration() doesn't return
> > the object, but rather falls through and returns the number of
> > nanoseconds in the final object:
> > --
> > my $dur = DateTime
On Mon, 30 Jun 2003, Ben Bennett wrote:
> The nits:
> 1) The following doesn't work because add_duration() doesn't return
> the object, but rather falls through and returns the number of
> nanoseconds in the final object:
> --
> my $dur = DateTime::Duration->new(months => 3)->add(hour
I want to create a duration that represents 3 hours shy of 3 months.
There is no way to do this directly using the new() constructor (Date::Manip
has 2 effective signs, one on years and months and the other on weeks,
days, hours, minutes and seconds).
You can get this by doing:
--
my $dur = DateT
On Sun, 29 Jun 2003, Joshua Hoblitt wrote:
> I just noticed your on MJD's lightning talk list for OSCON. What are
> you going to cram into 5 minutes? :)
Um, I dunno. I figured I'd write it that day or something. I'm mostly
planning on just telling people what the project is and why it's a good
Joshua Hoblitt wrote:
Are you in town yet? I've instigated a pdx.pm GT either Tues. or Weds. of this week.
Nope. I'll be getting in Saturday night (and probably wiped out until Sunday
morning). I'm open to suggestions of what to do on Sunday, though I won't be
getting a car unless provoked.
I
Joshua Hoblitt wrote:
> But it generates a makefile on win32 that calls Build so you can
> still use make, right? So the question is why does 'nmake' succeed
> and 'nmake test' fail?
This has been fixed in latest CVS. Basically, it was generating
a GNU makefile, not a "lowest common denominator"
Dave,
I just noticed your on MJD's lightning talk list for OSCON. What are you going to
cram into 5 minutes? :)
-J
--
Are you in town yet? I've instigated a pdx.pm GT either Tues. or Weds. of this week.
-J
--
30 matches
Mail list logo
