Re: definition of correctness

Thanks for the quick reply.

> I'm not sure what you're thinking might be busted here. If we're doing
> the same as POSIX::mktime does, then it's doing it right.

I think I was not very clear.  POSIX::mktime returns the same result for
2008-10-04T02:00:00 AEST+ 24 hrs and 2008-10-04T02:00:00 + 25 hrs, while
DateTime returns different results.

The problem I have is that now POSIX::mktime and DateTime return different
results when I do
arithmetic with hours.


-- POSIX::mktime
perl -MPOSIX -le 'print scalar localtime(mktime(0,0,2+24,4,9,108,0,0,-1))'
Sun Oct  5 03:00:00 2008
perl -MPOSIX -le 'print scalar localtime(mktime(0,0,2+25,4,9,108,0,0,-1))'
Sun Oct  5 03:00:00 2008
perl -MPOSIX -le 'print scalar localtime(mktime(0,0,2+48,4,9,108,0,0,-1))'
Mon Oct  6 02:00:00 2008

-- DateTime
perl -MDateTime -le '$dt = DateTime->new(day => 4, month => 10, year =>
2008, hour => 2, time_zone => "Australia/Melbourne"); print $dt->add(hours
=> 24)'
2008-10-05T03:00:00
perl -MDateTime -le '$dt = DateTime->new(day => 4, month => 10, year =>
2008, hour => 2, time_zone => "Australia/Melbourne"); print $dt->add(hours
=> 25)'
2008-10-05T04:00:00
perl -MDateTime -le '$dt = DateTime->new(day => 4, month => 10, year =>
2008, hour => 2, time_zone => "Australia/Melbourne"); print $dt->add(hours
=> 48)'
2008-10-06T03:00:00


The above differences are of concern because I have an application that uses
POSIX::mktime and I would love to refactor it using DateTime.

> When you add a day, you expect the wallclock to stay the same. "Tune in
> the same time tomorrow".

> When you add 24 hours, you expect 24 *HOURS* to elapse -- no matter how
> many hours there are in a day.

That makes sense, now that I think about it. I think the first rule of thumb
should be to stop equating a day with 24 hours when dealing with DST.