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.
