Re: [RFC] Data::ICal::DateTime

2005-08-10 Thread Simon Wistow 
On Tue, Aug 09, 2005 at 11:36:47AM +0100, Simon Wistow said:
 Which is all lovely and groovy but, since releasing, I've had the
 feeling that my TimeZone support is bogus - not least because if I do
 
   $span-set_time_zone('Europe/London');
 
 then I can wildly different results even though all the events in the 
 calendar have that TZID

I've found some oddness

With this VEVENT 

BEGIN:VEVENT
DTSTART;TZID=Europe/London:20050801T09
DTEND;TZID=Europe/London:20050801T13
SUMMARY:Mailman Day Reminder
UID:DF51C24D-0408-11DA-A793-000A9599EB44
SEQUENCE:7
DTSTAMP:20050803T102342Z
RRULE:FREQ=MONTHLY;INTERVAL=1;BYMONTHDAY=1
END:VEVENT


If I do this

my $start =  DateTime::Format::ICal-parse_datetime('20050801T13');
$start-set_time_zone('Europe/London');

my $recur = DateTime::Format::ICal-parse_recurrence(
recurrence = 
'FREQ=MONTHLY;INTERVAL=1;BYMONTHDAY=1',
dtstart = $start);

$recur-set_time_zone('Europe/London');

my $date1 = DateTime-new( year = 2005, month = 6, day = 27 );
my $date2 = DateTime-new( year = 2005, month = 10, day = 27 );
my $span  = DateTime::Span-from_datetimes(start=$date1, end=$date2);


my $int = $recur-intersection($span);

while (my $dt = $int-next) {
print $dt-ymd.\n;
}


then I get

2005-08-01
2005-09-01

but then 

2005-10-02

If I remove the $start-set_time_zone then I get 01 as expected. If I 
keep the $start-set_time_zone but lose the $recur-set_time_zone then I 
don't get it at all?

I'm baffled.

Could it be that my DateTime::* installation is horked? Or, as I 
suspect, am I doing something hideously wrong and/or misunderstanding 
something?

Simon

Re: [RFC] Data::ICal::DateTime

2005-08-10 Thread Flavio S. Glock 
Yes, I think it is a bug - RFC2445 shows some examples when DTSTART
has a timezone:

  DTSTART;TZID=US-Eastern:19970902T09
  RRULE:FREQ=DAILY;COUNT=10

The internal processing sequence should be changed to (pseudo code):

  $tz = $dtstart-tz
  $dtstart = $dtstart-floating
  return $recurr( $dtstart )-set_timezone( $tz )

- Flavio S. Glock

add(months) bug in DateTime-0.2901?

2005-08-10 Thread Flavio S. Glock 
I'm debugging a new failure in DateTime::Set t/15time_zone.t.
It fails with an infinite loop in this recurrence:

  my $months = DateTime::Set-from_recurrence(
 recurrence = sub {
$_[0]-truncate( to = 'month' )-add( months = 1 );
 }
 )
 -set_time_zone( 'Asia/Taipei' );

After adding the following debugging code:

  my $dt = $_[0]-clone;
  print $dt-datetime,'T',$dt-hms,\n;
  $dt-truncate( to = 'month' );
  print $dt-datetime,'T',$dt-hms,\n;
  $dt-add(months=1);
  print $dt-datetime,'T',$dt-hms,\n;
  print \n;

I got:

  2001-11-22T00:00:00T00:00:00
  2001-11-01T00:00:00T00:00:00
  2001-12-02T00:00:00T00:00:00

  2001-12-02T00:00:00T00:00:00
  2001-12-01T00:00:00T00:00:00
  2001-12-31T00:00:00T00:00:00

2001-12-01 + 1 month = 2001-12-31

- Flavio S. Glock

Re: add(months) bug in DateTime-0.2901?

2005-08-10 Thread Dave Rolsky 

On Wed, 10 Aug 2005, Flavio S. Glock wrote:


I'm debugging a new failure in DateTime::Set t/15time_zone.t.
It fails with an infinite loop in this recurrence:

 my $months = DateTime::Set-from_recurrence(
recurrence = sub {
   $_[0]-truncate( to = 'month' )-add( months = 1 );
}
)
-set_time_zone( 'Asia/Taipei' );

After adding the following debugging code:

 my $dt = $_[0]-clone;
 print $dt-datetime,'T',$dt-hms,\n;
 $dt-truncate( to = 'month' );
 print $dt-datetime,'T',$dt-hms,\n;
 $dt-add(months=1);
 print $dt-datetime,'T',$dt-hms,\n;
 print \n;

I got:

 2001-11-22T00:00:00T00:00:00
 2001-11-01T00:00:00T00:00:00
 2001-12-02T00:00:00T00:00:00

 2001-12-02T00:00:00T00:00:00
 2001-12-01T00:00:00T00:00:00
 2001-12-31T00:00:00T00:00:00

2001-12-01 + 1 month = 2001-12-31


Date math + time zones is somewhat borken right now.

I've been thinking about this and come to the conclusion that to not 
surprise _anyone_ we need to have separate math methods that distinguish 
between the local  UTC datetimes, because sometimes people want one and 
sometimes they want the other.  I think we may also want to mark durations 
as applying to UTC or local.


There were several recent bugs related to this that I fixed but the fix 
then broke other types of math, and the house of cards came tumbling down 
;)


I'll make a separate post detailing my proposed API changes.


-dave

/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg.   My book blog
===*/