Re: DateTime::Set, infinity, and recurrences
On Thu, 24 Jun 2004, Matt Sisk wrote: > Unless I'm missing something, it boils down to efficiency (why > pointlessly run a DT::Infinite object through its paces) vs edge cases > (probably some case of comparing a DT::Infinite to another DT::Infinite > and thereby getting caught in an infinite loop). The DT::Infinite subclass overrides many of the methods to do nothing (like set(), for example). -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Set, infinity, and recurrences
Matt Sisk wrote: > So why have the guard clause in the simple > examples presented in the DateTime::Set docs? Because I was not sure those examples would work without the test :) The examples were written before the code was finished. I guess I'll update the docs. So this is my TODO list for next versions: - update DateTime::Set POD - when/why to use the "is_infinite" test; update the examples. - add more POD on what happens if the parameter to next() is DateTime->now, or if the parameter has a time zone or a locale. - add tests for "what happens if the parameter to next() has a time zone or a locale" in DT::Event::Recurrence and DT::Event::ICal - Flavio S. Glock
Re: DateTime::Set, infinity, and recurrences
[EMAIL PROTECTED] wrote: If your recurrence specification is well-behaved, (don't use internals, etc) you don't have to test for infinite-ness. You only have to use " return $_[0] if $_[0]->is_infinite; " if your code can't handle DateTime::Infinite. As is wont with discussions of infinity, how to handle it can be pretty esoteric. I'd say 99% of the time (can't think of any counter examples) the right way to deal with infinity for next/previous *is* the line "return $_[0] if $_[0]->is_infinite". But I suppose what you're really saying is that, since DateTime::Infinite is a type of datetime, the short-circuit "return $_[0] if $_[0]->is_infinite" is not necessary if the normal operations you're performing on your datetimes are correctly (i.e. defined) handled by DateTime::Infinite. Unless I'm missing something, it boils down to efficiency (why pointlessly run a DT::Infinite object through its paces) vs edge cases (probably some case of comparing a DT::Infinite to another DT::Infinite and thereby getting caught in an infinite loop). So rephrased, you're saying that if the next/previous routines in the recurrence are complicated enough to trip up DT::Infinite comparisons, then they should also be complicated enough to take that into consideration. I suppose I can buy that. So why have the guard clause in the simple examples presented in the DateTime::Set docs? Matt
Re: DateTime::Set, infinity, and recurrences
This works fine, actually:
use DateTime::Set;
print $DateTime::Set::VERSION, "\n";
$months = DateTime::Set->from_recurrence(
recurrence => sub {
return $_[0]->truncate(
to => 'month' )->add( months => 1 )
},
);
print $months->next( DateTime->now )->datetime, "\n";
print $months->previous( DateTime->now )->datetime,
"\n";
# 0.16
# 2004-07-01T00:00:00
# 2004-06-01T00:00:00
If your recurrence specification is well-behaved,
(don't use internals, etc) you don't have to test
for infinite-ness.
You only have to use
" return $_[0] if $_[0]->is_infinite; "
if your code can't handle DateTime::Infinite.
So my vote goes for not changing the parameters...
- Flavio S. Glock
Re: DateTime::Set, infinity, and recurrences
On Thu, 24 Jun 2004, Matt Sisk wrote: > We actually would be changing the current capability, if not the current > behavior. Having 'detect_bounded' enabled by default would implement > what I discuss but not break anything that already detects bounds on its > own. > > Whether that's the right name or not...it seems okay to me, but other > ideas would include 'handle_infinite' (default 1), or > 'pass_on_boundaries' (default 0). handle_infinite sounds ok to me. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Set, infinity, and recurrences
We actually would be changing the current capability, if not the current behavior. Having 'detect_bounded' enabled by default would implement what I discuss but not break anything that already detects bounds on its own. Whether that's the right name or not...it seems okay to me, but other ideas would include 'handle_infinite' (default 1), or 'pass_on_boundaries' (default 0). Matt
Re: DateTime::Set, infinity, and recurrences
On Thu, 24 Jun 2004, Flavio S. Glock wrote: > > Really, did I dismiss it? I can't remember. But Matt's suggestion seemed > > reasonable. > > > > How about "detect_bounded => 1" for the current behaviour? > The default would be 0. I'm not sure that's the right parameter name. I can't even figure out what it does from the name ;) It seems like the current code _doesn't_ detect bounded, but you're saying the opposite. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Set, infinity, and recurrences
Dave Rolsky wrote: > > On Thu, 24 Jun 2004, Flavio S. Glock wrote: > > > Matt Sisk wrote: > > > > > > If a developer really had a need for handling infinite values, then this > > > wrapping could be explicitely disabled with a parameter in the constructor. > > > > > > > This was dismissed in a discussion here. > > Really, did I dismiss it? I can't remember. But Matt's suggestion seemed > reasonable. > How about "detect_bounded => 1" for the current behaviour? The default would be 0. - Flavio S. Glock
Re: DateTime::Set, infinity, and recurrences
On Thu, 24 Jun 2004, Flavio S. Glock wrote: > Matt Sisk wrote: > > > > If a developer really had a need for handling infinite values, then this > > wrapping could be explicitely disabled with a parameter in the constructor. > > > > This was dismissed in a discussion here. Really, did I dismiss it? I can't remember. But Matt's suggestion seemed reasonable. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Set, infinity, and recurrences
Matt Sisk wrote: > > If a developer really had a need for handling infinite values, then this > wrapping could be explicitely disabled with a parameter in the constructor. > This was dismissed in a discussion here. (the parameter "detect_bounded" is commented out in the code) - Flavio S. Glock
DateTime::Set, infinity, and recurrences
Hi All.
DateTime::Set was changed fairly recently in such a way as to
necessitate special handling of infinite datetimes in recurrences. This
isn't such a bad thing, but it does introduce complexity into even the
simplest of recurrences.
From the DateTime::Set docs:
# a 'monthly' recurrence:
$set = DateTime::Set->from_recurrence(
recurrence => sub {
return $_[0] if $_[0]->is_infinite;
return $_[0]->truncate( to => 'month' )->add( months => 1 )
},
span => $date_span1,# optional span
);
The operative line here is "return $_[0] if $_[0]->is_infinite". This
line, or something similar, now needs to be added to recurrence
specifications in order to avoid an infinite loop.
My question is why can't this be done automatically? So the following
(consider this to be pseudo-code):
recurrence => sub {
return $_[0]->truncate( to => 'month' )->add( months => 1 )
},
would internally be converted to this:
recurrence => sub {
return $_[0] if $_[0]->is_infinite;
&$recurrence(@_);
},
In case that's not clear -- take the intitial sub-ref and wrap the call
in another sub-ref that automatically deals with infinite values.
This would not break backwards compatability and would simplify the
lives of developers seeking "simple" recurrences.
If a developer really had a need for handling infinite values, then this
wrapping could be explicitely disabled with a parameter in the constructor.
Is this kind of nerfing of the API outweighed by the penalty of to
subroutine calls per iteration?
Thanks,
Matt
Re: Cron with TimeZone
On Thu, 24 Jun 2004, Dave Rolsky wrote: > Well, the docs say that now() always returns a UTC time. The reason being > that getting the local time zone is not always possible, so if we call > time() to get the current local epoch, we may not be able to figure out That should be localtime(), not time(). -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Cron with TimeZone
On Thu, 24 Jun 2004, Flavio S. Glock wrote: > Flavio S. Glock wrote: > > > > DateTime now() says: > > > > The default time zone is "floating". > > Oops, sorry - That's the docs for new() ! > > How come that now() and new() behave different? Because with now() we're actually getting a time associated with a time zone by calling gmtime() -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Cron with TimeZone
Flavio S. Glock wrote: > > DateTime now() says: > > The default time zone is "floating". Oops, sorry - That's the docs for new() ! How come that now() and new() behave different? - Flavio
Re: Cron with TimeZone
Flavio S. Glock wrote: > > the problem is that the default timezone for > now() is UTC, even if my TZ is set to another timezone... > DateTime now() says: The default time zone is "floating". However (tested in RedHat, Debian and FreeBSD): perl -MDateTime -e ' print DateTime->now->time_zone_long_name ' # UTC - Flavio S. Glock
Re: Cron with TimeZone
On Thu, 24 Jun 2004, Flavio S. Glock wrote:
> Matt Sisk wrote:
> >
> > Just to be clear, this is the native behavior of DateTime::Set, rather
> > than something that DateTime::Event::Cron is introducing into the sets
> > it generates. Using your same example, but replacing the cron set with
> > an actual (monthly) recurrence set, we see the same behavior:
> >
>
> That's right - the problem is that the default timezone for
> now() is UTC, even if my TZ is set to another timezone...
>
> $now = DateTime->now();
> print $now->strftime( "%a %F %T %Z\n");
> print $ENV{TZ},"\n";
> # Thu 2004-06-24 12:54:49 UTC
> # America/Sao_Paulo
Well, the docs say that now() always returns a UTC time. The reason being
that getting the local time zone is not always possible, so if we call
time() to get the current local epoch, we may not be able to figure out
the time zone. But calling gmtime() always works.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: Cron with TimeZone
Matt Sisk wrote:
>
> Just to be clear, this is the native behavior of DateTime::Set, rather
> than something that DateTime::Event::Cron is introducing into the sets
> it generates. Using your same example, but replacing the cron set with
> an actual (monthly) recurrence set, we see the same behavior:
>
That's right - the problem is that the default timezone for
now() is UTC, even if my TZ is set to another timezone...
$now = DateTime->now();
print $now->strftime( "%a %F %T %Z\n");
print $ENV{TZ},"\n";
# Thu 2004-06-24 12:54:49 UTC
# America/Sao_Paulo
- Flavio S. Glock
