On Mon, 5 Sep 2005, Dave Rolsky wrote:
could not get it to work sanely. I might take another crack at it if others
object, but I think that the current (in repo) behavior is at least
predictable, accurate, and reasonably sane (and documented).
So I started looking at this and remembered why this doesn't work at all.
Consider the case of two datetimes in the America/Chicago timezone:
2003-11-06T18:00:00
- 2003-05-06T18:00:00
======================
???????????????????
So what answer do we want? If we try to split it into local calendar +
UTC clock, we end up with this:
2003-11-06 00:00:00
- 2003-05-06 23:00:00
=======================
Now at this point we want to do the math thingy where we subtract one from
the day in the top datetime and add 24 hours (err, what's that word?).
That gives us this:
2003-11-05 24:00:00
- 2003-05-06 23:00:00
Then we subtract one month and add 31 days, getting:
2003-10-36 24:00:00
- 2003-05-06 23:00:00
========================
0 5 30 1 0 0
So we get 5 months, 30 days, and 1 hour. That is quite clearly not what
anyone would expect, and is damn near impossible to explain.
The other alternative is to simply use local for everything, but that
sucks pretty hard for subtraction on the same date crossing DST, for
example:
2003-04-06T03:01:00
- 2003-04-06T01:01:00
======================
0 0 0 2 0 0
Coming up with a 2 hour difference here just won't help, and again we have
the problem where the resulting duration, when added/subtracted from the
one endpoint does not give us the other endpoint.
So I think doing it all in UTC is really the best choice. I think the
user actually needs to decide whether they want calendar or calendar +
clock math. In many many cases they will only care about the calendar
portion, and can use delta_md() or delta_days().
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
