I have actually been thinking about that a bit...
The way it is shaping up is that it will be a generic DT::SpanSet
wandering thing... So given a SpanSet (or Set, or Span) it will be
able to do operations within its context (i.e. date arithmetic,
etc.).
DT::E::BusinessDay would simply be a superc
> Hang on a second .. isn't this all a part of DateTime::Event::BusinessDay?
Maybe BusinessDay doesn't describe the functionality all that well then. :)
At 3:24 PM -1000 16/6/03, Joshua Hoblitt wrote:
> > There must be a way to express the same semantic
> meaning with fewer lines of code
A slightly smaller version - specify days and hours
in the same constructor.
That is a bit clearer - although it's alot more code then I'd want
to inline in
> > There must be a way to express the same semantic
> > meaning with fewer lines of code
>
> A slightly smaller version - specify days and hours
> in the same constructor.
That is a bit clearer - although it's alot more code then I'd want to inline in a
program. It's something I would push off
Ah! nice. I don't fully understand DT:E:Recurrence yet...
Slight correction to both scripts:
The hours should be 13 and 17 instead of 1 and 5 (damn PM...).
Then yours should be (otherwise it picks up Saturdays too):
days => [1..5]
Which is more clear than mine anyway...
-ben
Joshua Hoblitt said:
> There must be a way to express the same semantic
> meaning with fewer lines of code
A slightly smaller version - specify days and hours
in the same constructor.
- Flavio S. Glock
---
#!/usr/local/bin/perl -w
use strict;
use DateTime;
use DateTime::Span;
use DateTime::Span
On Mon, 16 Jun 2003, Ben Bennett wrote:
> Most of the code below is building the ranges... I think youy would
> have to do that anyway. The real bit that the module would do is the
> intersection stuff, and that is a couple of lines.
There must be a way to express the same semantic meaning with f
Ok, lets say that you want only "working hours" as legal times, so
9-12,1-5, M-F from July 1st to July 17th, 2003.
Most of the code below is building the ranges... I think youy would
have to do that anyway. The real bit that the module would do is the
intersection stuff, and that is a couple of l
> my $safe_span = ...;# Whatever you need
> my dt = DateTime->new(...);
> croak "Bad date range" if $safe_span->contains($dt);
In my [poor] example. But what if you only wanted to only accept time values from
11:00-18:00 across a span?
> In fact you may want the span to be a spanset to
Isn't that simply:
my $safe_span = ...;# Whatever you need
my dt = DateTime->new(...);
croak "Bad date range" if $safe_span->contains($dt);
In fact you may want the span to be a spanset to accomodate more fine
grained controls. Is this useful enough to merit a class? I dunno.
As a mino
Iain Truskett schreef:
> That version isn't on CPAN yet. To be honest, I'd really
> like the validation to be optional. While some people have
> more use for validation rather than normalization, others
> (like me) are the opposite =)
It could even be useful to have partial normalization: die on
2
Hello All,
I can't find the past posts, so please do not ambush me when I ask
something that someone else might have asked before.
I noticed that DateTime.pm automatically normalize dates. For example if
one were to enter 13 as month, it automatically add one year to the
current year, and chan
I half agree. Initially I thought that it should be optional and said
so on the list. Dave replied saying that he wouldn't make it so
unless anyone had an example of why it needed to be optional.
So far I haven't come up with a reasonable one. If you have a real
case mail it to the list.
So the
On Mon, Jun 16, 2003 at 12:01:21PM +1000, Iain Truskett wrote:
>
> That version isn't on CPAN yet. To be honest, I'd really
> like the validation to be optional. While some people have
> more use for validation rather than normalization, others
> (like me) are the opposite =)
I half agree. Initia
> That version isn't on CPAN yet. To be honest, I'd really
> like the validation to be optional. While some people have
> more use for validation rather than normalization, others
> (like me) are the opposite =)
>
> Even just another arg: normalize => 1 or something?
I'm not really sure what the
15 matches
Mail list logo
