Dave Rolsky schreef:
> But in fact, one hour less than 6 months has passed because of the DST
> change
I think this is a very strange thing to say, as the duration "6 months"
is never a fixed amount of hours, not even in UTC.
> In this case, we added 6 months to the _UTC_ time and the displayed clock
> time changes, due to DST. This is also a reasonable result, since it
> reflects the actual amount of time that has passed.
I don't think it is reasonable, and I can't remember anyone complaining
about this. Can you give a reference? [*]
> So what's the solution?
>
> I think we need to have dual sets of methods, one for local and one for
> UTC:
I don't like it. The proper solution IMHO would be to do the calculation
in utc, if that is what you want:
$localzone = $dt1->time_zone;
$dt1 = $dt1->set_timezone('utc')
->add_duration(months => 6)
->set_timezone($localzone);
It's not a common problem, as far as I can see, at least not for people
who work with "local" times. They (almost?) never want to account for
leap hours when subtracting datetimes in July and December, for
instance.
1 day is just not always the same as 24 hours, in timezones with DST.
That's how DateTime has always worked; that is how it should work.
Eugene
[*] According to the Changes file, the change to calculations in UTC was
prompted by a bug report by Mike Schilli. I can't find this report; do
you know what the problem was?
