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
===*/
