More flexibly subtract/difference methods

2003-10-09 Thread Dave Rolsky
So there was some talk about this earlier and I was thinking about how
best to make this information available.

Currently, the default when subtracting datetimes is to break down the
duration into multiple parts, months, days, minutes, seconds, and
nanoseconds.

>From the months piece we can derive years, and from the days piece we can
derive weeks.

There's also the subtract_datetime_absolute method, which just returns
seconds and nanoseconds.  I see the primary purpose of this method as
returning an object which can be used to repeatedly add or subtract a very
specific absolute length duration.

But some people have indicated that they'd like something a little more
flexible.  Eugene van der Pijll suggested something like this:

 my $dur = $dt1->difference( datetime => $dt2,
 units=> [ 'months', 'days' ] );

This would return a duration which only included month and day values,
without minutes, seconds, or nanoseconds.

This has some obvious uses, as does requesting only days when you'd rather
get back "45 days" than "1 month, 14 days".

So this makes sense to me.

_BUT_ ...

Do we really need such a flexible API?  For example, will anyone ever want
to do this:

 my $dur = $dt1->difference( datetime => $dt2,
 units=> [ 'months', 'nanoseconds' ] );

My guess is that the answer here is no.

So perhaps rather than providing the above API, we should instead offer
something like this (taking a page from Date::Calc):

 # months & days
 my $dur = $dt->delta_md($dt2);

 # days only
 my $dur = $dt->delta_days($dt2);

 # hours, minutes and seconds only
 my $dur = $dt->delta_hms($dt2);

It seems to me that these 3 cover all the important possibilities, and
they have a nice simple API.

Flavio, you'd mentioned something about wanting to get years back as a
unit, but that didn't make much sense to me.  Years is _always_ equal to
"months * 12", so if we have:

 my $dur = $dt->delta_md($dt2);

then "$dur->years" will give you what you want, right?


Anyway, comments on the above API are welcome.


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/


DateTime::Set conditional offset, remove datetimes

2003-10-09 Thread fglock
DateTime::Set in cvs:

=item * iterate

Experimental method - subject to change.

This method apply a callback subroutine to all
elements of a set.

sub callback {
$_[0]->add( hours => 1 );
}

# offset $set elements by one hour
$set->iterate( \&callback );  

# $set2 elements are one hour after $set
elements, and
# $set is unchanged
$set2 = $set->clone->iterate( \&callback );  

If the callback returns C, the datetime is
removed from the set:

sub remove_sundays {
$_[0] unless $_[0]->day_of_week == 7;
}

The callback can be used to postpone or anticipate
events which collide with datetimes in another set:

sub after_holiday {
$_[0]->add( days => 1 ) while
$holidays->contains( $_[0] );
}


- Flavio S. Glock




Re: [Announce] DateTime-event-sunrise 0.0401 committed to CVS

2003-10-09 Thread fglock
Ronald Hill said:
>
> This will not preserve the class information,
> I tried Flavio's suggestion of
> 
> my $tmp_dt1 = $dt->
>  clone->
>  set_time_zone( 'UTC' )->
>  truncate( to => 'day' );
> 
> instead of creating a new object however, 
> I was always getting the incorrect
> date returned.

It may be that setting UTC is changing the
day, because you already have a time zone.
Would you try this instead?

 my $tmp_dt1 = $dt->
  clone->
  set_time_zone( 'floating' )->
  set_time_zone( 'UTC' )->
  truncate( to => 'day' );

It means: "forget about your time zone, and
give me the start of this day number in UTC."

This is untested.

- Flavio S. Glock




[Announce] DateTime-event-sunrise 0.0401 committed to CVS

2003-10-09 Thread Hill, Ronald
Hi All,

I have just committed changes to the sunrise module for preserving the
timezone information. I have to confess I do not like how I had to do it :(

Here is how I have changed the _sunrise sub

  my $rise_time = $tmp_dt1 + $rise_dur;
  my $set_time  = $tmp_dt1 + $set_dur;
  my $tz = $dt->time_zone;
  $rise_time->set_time_zone($tz) unless $tz->is_floating;
  $set_time->set_time_zone ($tz) unless $tz->is_floating;
  return ( $rise_time, $set_time );

This will not preserve the class information, I tried Flavio's suggestion of

my $tmp_dt1 = $dt->
 clone->
 set_time_zone( 'UTC' )->
 truncate( to => 'day' );

instead of creating a new object however, I was always getting the incorrect
date returned.

So I reverted back to creating a new object and setting the timezone of the
new object.

Thanks

Ron Hill


Re: [PATCH] Several fixes to DateTime::TimeZone 0.2503

2003-10-09 Thread Alexey Mahotkin
> "DR" == Dave Rolsky <[EMAIL PROTECTED]> writes:

RM> Rather than this, maybe we need to add a note to all modules
RM> to signify that $datetime and $dt refer to DateTime.pm
RM> objects.
>>  That's ok, but _something_ should be said about $datetime.  I
>> passed time() at first, and was surprised to see the
>> diagnostics.

DR> I just noticed that every method's docs says this:

DR>   Given an object which implements the DateTime.pm API, ...

DR> That's pretty clear, I think.

At the very least I think that the Synopsis must be updated.


I've just noticed that too!  I guess that's a suggestion for
improvement (no jokes about improvement of my cognitive abilities,
please).

I believe that arguments description could be moved after the
function description.  Current situation is an RPL-ism.

--alexm



Re: SpanSet Issues and Requests

2003-10-09 Thread fglock
I've done some diagrams, in order to check if
you agree with the semantics of these SpanSet
functions.

Some of these operations can be interpreted
in more than one way. If you think something
should be different, please let me know.

This is the notation used:
  [aaa] - a closed spanset or span
  (aaa) - an open set
  [aaa) - semi-open set
  ()- empty set
  dt- a datetime object

---
>   next( $dt )

given: [  aa   bb ]
  ^dt
returns:  [bb]

given: [  aaabbb  ]
 ^dt
returns: [aaabbb]
could also be:  (bbb]

given: [  aaa   ]
  ^dt
returns:()

---
>   previous( $dt )

given: [  aa   bb ]
  ^dt
returns: [aa]

given: [  aaabbb  ]
 ^dt
returns: [aaabbb]
could also be:  [aaa)

given: [  aaa   ]
   ^dt
returns:()

---
>   current( $dt )

given: [  aa   bb ]
  ^dt
returns: [aa]

given: [  aaabbb  ]
 ^dt
returns: [aaabbb]
could also be:  dt

given: [  aaa   ]
   ^dt
returns:()

given: [  aaa   ]
  ^dt
returns: [aaa]

---
>   closest( $dt )

given: [  aa   bb ]
  ^dt
returns: [aa]

given: [  aa   ]
 ^dt
returns: [aa]
could also be:  dt

---
>   as_list

given: [  aa   bb ]

returns: [aa],[bb]
---

- Flavio S. Glock




RE: DT-subtraction bugs in DT::F::Excel and DT::Event::Sunrise

2003-10-09 Thread Dave Rolsky
On Thu, 9 Oct 2003, Hill, Ronald wrote:

> F:\perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0,
> 'blib\lib', 'blib\arch
> )" t\00load.t t\01basic.t
> t\00load.ok
> t\01basicNOK 1# Failed test (t\01basic.t at line 35)
> #  got: '2000-06-19T07:54:00'
> # expected: '2000-06-19T05:43:00'
> t\01basicNOK 2# Failed test (t\01basic.t at line 36)
> #  got: '2000-06-19T18:10:00'
> # expected: '2000-06-19T20:03:00'
> t\01basicNOK 3# Failed test (t\01basic.t at line 38)
> #  got: '2000-06-19T07:54:00'
> # expected: '2000-06-19T05:43:00'
> t\01basicNOK 4# Failed test (t\01basic.t at line 40)
> #  got: '2000-06-19T18:10:00'
> # expected: '2000-06-19T20:03:00'
> t\01basicNOK 5# Failed test (t\01basic.t at line 43)
> #  got: '2000-06-20T07:54:00'
> # expected: '2000-06-20T05:43:00'
> t\01basicNOK 6# Failed test (t\01basic.t at line 45)
> #  got: '2000-06-20T18:11:00'
> # expected: '2000-06-20T20:03:00'
> t\01basicNOK 7# Failed test (t\01basic.t at line 48)
> #  got: '2000-06-18T07:54:00'
> # expected: '2000-06-18T05:43:00'
> t\01basicNOK 8# Failed test (t\01basic.t at line 50)
> #  got: '2000-06-18T18:09:00'
> # expected: '2000-06-18T20:03:00'
> t\01basicNOK 13# Failed test (t\01basic.t at line 74)
> t\01basicok 15/15# Looks like you failed 9 tests of 15.
> t\01basicdubious

I just checked in a stopgap fix, which is to use

 int($dt->jd - $base_date->jd)

In a future version of DateTime, there will be a method to subtract two
datetimes and get your choice of units back, but for now this should work
fine.


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/


Re: [PATCH] Several fixes to DateTime::TimeZone 0.2503

2003-10-09 Thread Dave Rolsky
On Thu, 9 Oct 2003, Alexey Mahotkin wrote:

> At the very least I think that the Synopsis must be updated.

I agree.

> I believe that arguments description could be moved after the
> function description.  Current situation is an RPL-ism.

Huh?  I think the current method descriptions are pretty sensible.
"Given X, does Y".


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/


Re: [PATCH] Several fixes to DateTime::TimeZone 0.2503

2003-10-09 Thread Dave Rolsky
On Thu, 9 Oct 2003, Alexey Mahotkin wrote:

> RM> DateTime-TimeZone-0.2503/lib/DateTime/TimeZone.pm SYNOPSIS
> >> + use DateTime; + my $datetime = DateTime->now(); + my $offset
> >> = $tz->offset_for_datetime($datetime);
>
> RM> Rather than this, maybe we need to add a note to all modules
> RM> to signify that $datetime and $dt refer to DateTime.pm
> RM> objects.
>
> That's ok, but _something_ should be said about $datetime.  I passed
> time() at first, and was surprised to see the diagnostics.

I just noticed that every method's docs says this:

  Given an object which implements the DateTime.pm API, ...

That's pretty clear, I think.


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/


Re: SpanSet Issues and Requests

2003-10-09 Thread Dave Rolsky
On Thu, 9 Oct 2003, Flavio S. Glock wrote:

> DT::SpanSet misses all these methods:
>   next( $dt )
>   previous( $dt )
>   current( $dt )
>   closest( $dt )
>   as_list
>
> Is it ok to implement this in DT::SpanSet?

Please do!


/*===
House Absolute Consulting
www.houseabsolute.com
===*/


Re: [PATCH] Several fixes to DateTime::TimeZone 0.2503

2003-10-09 Thread Dave Rolsky
On Thu, 9 Oct 2003, Alexey Mahotkin wrote:

> I've installed DateTime::TimeZone 0.2503 from CPAN under the Perl
> 5.8.1 and noticed the following glitches, which are fixed in the patch
> below and described in Changes.

Actually, there's intentionally no dependency on DateTime, since DateTime
depends on DateTime::TimeZone.  You'll notice that each test starts with:

 BEGIN { require 'check_datetime_version.pl' }

This will check to see if DateTime.pm is already installed.  If not, it
skips the tests.  This allows DT::TZ to be installed before DateTime.pm.

I'll apply the rest of the patch though.


-dave

/*===
House Absolute Consulting
www.houseabsolute.com
===*/



SpanSet Issues and Requests

2003-10-09 Thread Rick Measham
G'day Flavio,

I'm doing some intensive SpanSet stuff and I'm thinking you might be
able to answer a couple of questions:

I'm trying to get next/previous spans from a given DateTime. I'm
defining next/previous as the event who started before or after $dt.
Where it ends doesn't matter, even if we're still in the middle of the
event.

To get the 'next' I'm intersecting with a span starting at $dt and
ending at +inf. Then I get $iterator->next. I return it unless the
spanset contains $dt. If it does then I return $iterator->next.

This seems a lot to do to get the next span after a particular $dt.

However, to get the previous is even worse!

Once again I intersect with -inf to $dt. Then if the spanset contains
$dt, I get the max of the complement of the intersection. This is the
start of the span I want. Now to get then end of it, I can't see any
other way than to intersect the original span with $dt to +inf. Which
seems like craziness to me!

If we're not in the middle of a span, it goes on! First I get the max of
the -inf to $dt spanset intersection. That's the end of the span I want,
lets call that $dt2. I then get the max of the complement of -inf to
$dt2, that's the start of the span.

All the above takes time. Seconds in fact! Surely there's a better way
... I'd really like to have $spanset->next_span($dt) and
$spanset->previous_span($dt) but if there's some way to do it myself
that is better than what I'm doing I'd love to know.

Thanks and Cheers!
Rick Measham



Re: [PATCH] Several fixes to DateTime::TimeZone 0.2503

2003-10-09 Thread Alexey Mahotkin
> "RM" == Rick Measham <[EMAIL PROTECTED]> writes:

>> DateTime-TimeZone-0.2503/Build.PL + 'DateTime' => 0,

RM> If you do that, then you can't install it :) DateTime requires
RM> that DateTime::TimeZone be installed before it will
RM> install. So if you make DateTime::TimeZone require that
RM> DateTime be installed, then neither can install.

Ouch!  Ok, this could be fixed by more documentation and clearer
diagnostics.


>> DateTime-TimeZone-0.2503/lib/DateTime/TimeZone.pm + die
>> "Invalid time zone name: $p{name}\n$@" if $@;

RM> This is a good suggestion, but returning $@ doesn't happen in
RM> many (any?)  (IIRC) other places in DateTime. Personally I'd
RM> like to get back confess() rather than die .. then you know
RM> where it went wrong.

Here $@ is set by eval.  There should not be more "other places".
Replacing `die' with `confess' is orthogonal here.  I guess most times
the problem will be in missing DateTime.pm module.  So that should be
diagnosed clearly.

You can check for more exact contents of $@:

my $module_name = "Foo::Bar::Baz";

eval "require $module_name;";

if ($@){

 # Foo::Bar::Baz ==> Foo/Bar/Baz.pm
 (my $module_filename = $module_name) =~ s,::,/,g;
 $module_filename .= ".pm";

 if ($@ =~ /^Can't locate \Q$module_filename\E/)) {
   # the constructed module itself not found
   die "Timezone '$timezone_name' not found or invalid";
 } else {
   # missing DateTime.pm, or typo in module, or something else

   die; # propagating $@
 }
}

I use dynamically-constructed module names a lot, and always use this
technology.


RM> DateTime-TimeZone-0.2503/lib/DateTime/TimeZone.pm SYNOPSIS
>> + use DateTime; + my $datetime = DateTime->now(); + my $offset
>> = $tz->offset_for_datetime($datetime);

RM> Rather than this, maybe we need to add a note to all modules
RM> to signify that $datetime and $dt refer to DateTime.pm
RM> objects.

That's ok, but _something_ should be said about $datetime.  I passed
time() at first, and was surprised to see the diagnostics.


Thanks,

--alexm


Re: SpanSet Issues and Requests

2003-10-09 Thread Flavio S. Glock
Rick Measham wrote:
> 
> I'm trying to get next/previous spans from a given DateTime. I'm
> defining next/previous as the event who started before or after $dt.
> Where it ends doesn't matter, even if we're still in the middle of the
> event.

Here is an example (tested):
---
use strict;
use DateTime::Span;

# build a spanset
my $span1 = DateTime::Span->new(
start => DateTime->new( year => 2000 ),
end   => DateTime->new( year => 2003 ) );
my $span2 = DateTime::Span->new(
start => DateTime->new( year => 2006 ),
end   => DateTime->new( year => 2009 ) );
my $span3 = DateTime::Span->new(
start => DateTime->new( year => 2012 ),
end   => DateTime->new( year => 2015 ) );
my $spanset = $span1->union( $span2 )->union( $span3 );
print "SpanSet ".$spanset->{set}."\n";
print "\n";

my $dt = DateTime->new( year => 2005 );

for ( 1 .. 3 )
{
  print "dt: ".$dt->datetime."\n";
  my $after  = DateTime::Span->new( start => $dt );
  my $before = DateTime::Span->new( end => $dt );

  my $next = $after->intersection( $spanset )->next;
  my $previous = $before->intersection( $spanset )->previous;

  print "next: ".$next->{set}."\n";
  print "previous: ".$previous->{set}."\n";
  print "\n";

  $dt->add( years => 3 );
}
---
SpanSet
[2000-01-01T00:00:00..2003-01-01T00:00:00],[2006-01-01T00:00:00..2009-01-01T00:00:00],[2012-01-01T00:00:00..2015-01-01T00:00:00]

dt: 2005-01-01T00:00:00
next: [2006-01-01T00:00:00..2009-01-01T00:00:00]
previous: [2000-01-01T00:00:00..2003-01-01T00:00:00]

dt: 2008-01-01T00:00:00
next: [2008-01-01T00:00:00..2009-01-01T00:00:00]
previous: [2006-01-01T00:00:00..2008-01-01T00:00:00]

dt: 2011-01-01T00:00:00
next: [2012-01-01T00:00:00..2015-01-01T00:00:00]
previous: [2006-01-01T00:00:00..2009-01-01T00:00:00]
---

> All the above takes time. Seconds in fact! 

It was not noticeably slow here. Would you test this?

> Surely there's a better way
> ... I'd really like to have $spanset->next_span($dt) and
> $spanset->previous_span($dt) but if there's some way to do it myself
> that is better than what I'm doing I'd love to know.

DT::SpanSet misses all these methods:
  next( $dt )
  previous( $dt )
  current( $dt )
  closest( $dt )
  as_list

Is it ok to implement this in DT::SpanSet?

- Flavio S. Glock


Re: RFC: conditional DateTime::Set->add_duration

2003-10-09 Thread Flavio S. Glock
Flavio S. Glock wrote:
> 
> > How about having a generic method that anticipates or
> > postpones an event, if it falls in an invalid date.
> > For example:
> 
>   $payday_set = DateTime::Event::Recurrence->monthly(
>   days => -1,
>   );
> 
[...]
> >   # subtract days from "payday" events,
> >   # such that they never fall in a weekend

Another way to do it:

  $payday_set->iterate(
  sub {
  my $dt = shift;
  my $dow = $dt->day_of_week;
  $dt->add( days => 5 - $dow ) if $dow > 5;
  return $dt;
  }
  );

> Result: $payday_set is a set of "last day of the month that is not a
> weekend"

Another one: move or delete holidays such that they don't fall in the
middle of the week:

  $holiday_set->iterate(
  sub {
  my $dt = shift;
  my $dow = $dt->day_of_week;
  return undef if $dow == 3;   # delete this event
  return $dt->add( days => 1 )  if $dow == 4;
  return $dt->add( days => -1 ) if $dow == 2;
  return $dt;   # don't move
  }
  );

- Flavio S. Glock


RE: DT-subtraction bugs in DT::F::Excel and DT::Event::Sunrise

2003-10-09 Thread Hill, Ronald
Hi Dave,

> 
> 
> On Tue, 7 Oct 2003, Hill, Ronald wrote:
> 
> > Thanks for that!! I just started looking at the sunrise module
> > to do some updates for preserving the timezone.
> >
> > I just installed the new release of DateTime 0.1704
> > and all tests now pass for sunrise :)
> 
> 0.1704 is really broken so try it again with 0.1705 just to 
> make sure ;)
> 

Oh dear!!
I have installed the new DateTime update and tests for sunrise
fail :(

the 04 version was working. Here is the results

F:\perl_modules\DateTime-0.1704>perl makefile.pl
Testing if you have a C compiler

Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

cl  /c test.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

test.c
Checking if your kit is complete...
Looks good
Writing Makefile for DateTime

F:\perl_modules\DateTime-0.1704>nmake

Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

cp lib/DateTime.pm blib\lib\DateTime.pm
cp lib/DateTimePP.pm blib\lib\DateTimePP.pm
cp lib/DateTime/Duration.pm blib\lib\DateTime/Duration.pm
cp lib/DateTimePPExtra.pm blib\lib\DateTimePPExtra.pm
cp lib/DateTime/Infinite.pm blib\lib\DateTime/Infinite.pm
cp lib/DateTime/LeapSecond.pm blib\lib\DateTime/LeapSecond.pm
F:\perl\bin\perl.exe F:\Perl\lib\ExtUtils/xsubpp  -typemap
F:\Perl\lib\ExtUtils\typemap
eTime.xs > DateTime.xsc && F:\perl\bin\perl.exe -MExtUtils::Command -e mv
DateTime.xsc DateTime.c
cl -c-nologo -Gf -W3 -MD -DNDEBUG -O1 -DWIN32 -D_CONSOLE
-DNO_STRICT -DHAVE_DES_FCRYP
DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO
-DPERL_MSVCRT_READFIX -MD -DNDEBUG -O1
VERSION=\"0.1704\"  -DXS_VERSION=\"0.1704\"  "-IF:\Perl\lib\CORE"
DateTime.c
DateTime.c
DateTime.xs(129) : warning C4244: '=' : conversion from 'double ' to 'long
', possible loss of da
"Running Mkbootstrap for DateTime ()"
F:\perl\bin\perl.exe -MExtUtils::Command -e chmod 644 DateTime.bs
F:\perl\bin\perl.exe -MExtUtils::Mksymlists  -e
"Mksymlists('NAME'=>\"DateTime\", 'DLBASE
> 'DateTime', 'DL_FUNCS' => {  }, 'FUNCLIST' => [], 'IMPORTS' => {  },
'DL_VARS' => []);"
link -out:blib\arch\auto\DateTime\DateTime.dll -dll -nologo
-nodefaultlib -release  -libp
:"C:\Perl\lib\CORE"  -machine:x86 DateTime.obj   F:\Perl\lib\CORE\perl58.lib
oldnames.lib kernel3
ib user32.lib gdi32.lib winspool.lib  comdlg32.lib advapi32.lib shell32.lib
ole32.lib oleaut32.li
netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib  version.lib odbc32.lib
odbccp32.lib msvcrt.l
-def:DateTime.def
   Creating library blib\arch\auto\DateTime\DateTime.lib and object
blib\arch\auto\DateTime\DateT
.exp
F:\perl\bin\perl.exe -MExtUtils::Command -e chmod 755
blib\arch\auto\DateTime\DateTime.dl
F:\perl\bin\perl.exe -MExtUtils::Command -e cp DateTime.bs
blib\arch\auto\DateTime\DateTi
bs
F:\perl\bin\perl.exe -MExtUtils::Command -e chmod 644
blib\arch\auto\DateTime\DateTime.bs

F:\perl_modules\DateTime-0.1704>nmake install

Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

Skipping F:\Perl\site\lib\auto\DateTime\DateTime.bs (unchanged)
Installing F:\Perl\site\lib\auto\DateTime\DateTime.dll
Installing F:\Perl\site\lib\auto\DateTime\DateTime.exp
Installing F:\Perl\site\lib\auto\DateTime\DateTime.lib
Installing F:\Perl\site\lib\DateTime.pm
Skipping F:\Perl\site\lib\DateTimePP.pm (unchanged)
Skipping F:\Perl\site\lib\DateTimePPExtra.pm (unchanged)
Installing F:\Perl\site\lib\DateTime\Duration.pm
Skipping F:\Perl\site\lib\DateTime\Infinite.pm (unchanged)
Skipping F:\Perl\site\lib\DateTime\LeapSecond.pm (unchanged)
Writing F:\Perl\site\lib\auto\DateTime\.packlist
Appending installation info to F:\Perl\lib/perllocal.pod

F:\perl_modules\DateTime-0.1704>g:

G:\>cd modules

G:\modules>cd datetime-event-sunrise


G:\modules\DateTime-Event-Sunrise>perl makefile.pl
Checking if your kit is complete...
Looks good
Writing Makefile for DateTime::Event::Sunrise

G:\modules\DateTime-Event-Sunrise>nmake

Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

cp lib/DateTime/Event/Sunrise.pm blib\lib\DateTime/Event/Sunrise.pm

G:\modules\DateTime-Event-Sunrise>nmake test

Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

F:\perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0,
'blib\lib', 'blib\ar
)" t\00load.t t\01basic.t
t\00load.ok
t\01basicok
All tests successful.
Files=2, Tests=16,  1 wallclock secs ( 0.00 cusr +  0.00 csys =  0.00 CPU)

G:\modules\DateTime-Event-Sunrise>

G:\modules\DateTime-Event-Sunrise>f:

F:\perl_modules\DateTime-0.1704>cd ..

F:\perl_modules>cd datetime-0.1705

F:\perl_

Re: [PATCH] Several fixes to DateTime::TimeZone 0.2503

2003-10-09 Thread Rick Measham
Alexey Mahotkin wrote:
> I've installed DateTime::TimeZone 0.2503 from CPAN under the Perl
> 5.8.1 and noticed the following glitches, which are fixed in the patch
> below and described in Changes.

They don't appear to be glitches but suggestions :)

> DateTime-TimeZone-0.2503/Build.PL
> +  'DateTime' => 0,

If you do that, then you can't install it :)
DateTime requires that DateTime::TimeZone be installed before it will
install. So if you make DateTime::TimeZone require that DateTime be
installed, then neither can install.


> DateTime-TimeZone-0.2503/lib/DateTime/TimeZone.pm
> +die "Invalid time zone name: $p{name}\n$@" if $@;

This is a good suggestion, but returning $@ doesn't happen in many
(any?)
(IIRC) other places in DateTime. Personally I'd like to get back
confess()
rather than die .. then you know where it went wrong.

DateTime-TimeZone-0.2503/lib/DateTime/TimeZone.pm 
SYNOPSIS
> +  use DateTime;
> +  my $datetime = DateTime->now();
> +  my $offset = $tz->offset_for_datetime($datetime);

Rather than this, maybe we need to add a note to all modules to signify
that
$datetime and $dt refer to DateTime.pm objects.

> +C objects provide the following methods
($datetime
> +is assumed to be an instance of DateTime class):

See above.

Thanks for your suggestions Alexey!

Cheers!
Rick






[PATCH] Several fixes to DateTime::TimeZone 0.2503

2003-10-09 Thread Alexey Mahotkin

Hello,

I've installed DateTime::TimeZone 0.2503 from CPAN under the Perl
5.8.1 and noticed the following glitches, which are fixed in the patch
below and described in Changes.

Please apply something along the lines of the attached patch.


Thank you,


diff -ruN --exclude *~ DateTime-TimeZone-0.2503.orig/Changes 
DateTime-TimeZone-0.2503/Changes
--- DateTime-TimeZone-0.2503.orig/Changes   Mon Oct  6 22:04:19 2003
+++ DateTime-TimeZone-0.2503/ChangesThu Oct  9 14:56:07 2003
@@ -1,3 +1,11 @@
+0.2503-alexm:w-m.ru   2003-10-09
+
+- Add dependency on DateTime;
+
+- Show more details on _why_ the timezone name is "invalid";
+
+- Clarify the meaning of $datetime argument;
+
 0.2503   2003-10-06
 
 - Made the offset string -> number conversion slightly less strict, so
diff -ruN --exclude *~ DateTime-TimeZone-0.2503.orig/Build.PL 
DateTime-TimeZone-0.2503/Build.PL
--- DateTime-TimeZone-0.2503.orig/Build.PL  Tue Sep  9 20:35:20 2003
+++ DateTime-TimeZone-0.2503/Build.PL   Thu Oct  9 14:52:20 2003
@@ -26,6 +26,7 @@
 license => 'perl',
 requires=> { 'Params::Validate' => 0,
  'Class::Singleton' => 1.03,
+'DateTime' => 0,
},
sign=> 1,
   )->create_build_script;
diff -ruN --exclude *~ DateTime-TimeZone-0.2503.orig/lib/DateTime/TimeZone.pm 
DateTime-TimeZone-0.2503/lib/DateTime/TimeZone.pm
--- DateTime-TimeZone-0.2503.orig/lib/DateTime/TimeZone.pm  Mon Oct  6 21:51:52 
2003
+++ DateTime-TimeZone-0.2503/lib/DateTime/TimeZone.pm   Thu Oct  9 14:55:37 2003
@@ -66,7 +66,7 @@
 my $real_class = "DateTime::TimeZone::$subclass";
 
 eval "require $real_class";
-die "Invalid time zone name: $p{name}" if $@;
+die "Invalid time zone name: $p{name}\n$@" if $@;
 
 return $real_class->instance( name => $p{name}, is_olson => 1 );
 }
@@ -406,10 +406,14 @@
 
 =head1 SYNOPSIS
 
+  use DateTime;
   use DateTime::TimeZone
 
   my $tz = DateTime::TimeZone->new( name => 'America/Chicago' );
 
+  my $datetime = DateTime->now();
+  my $offset = $tz->offset_for_datetime($datetime);
+
 =head1 DESCRIPTION
 
 This class is the base class for all time zone objects.  A time zone
@@ -486,7 +490,8 @@
 
 =head2 Object Methods
 
-C objects provide the following methods:
+C objects provide the following methods ($datetime
+is assumed to be an instance of DateTime class):
 
 =over 4
 
--alexm