Ahh ok, you mean then
mid_date = startdate + (end_date-start_date)/2
Your attitude is baffling. You deny that adding dates makes sense,
and when I post an example where adding dates makes perfect sense, you
respond by asserting that I mean some other expression that achieves
that same effect. The mere fact that you were able to post another
expression with the same meaning refutes your original claim.[/QUOTE]
Mr Navia's attitude makes sense if you think of dates in "homogenous
coordinates".
It's common in 3D graphics to use 4-vectors to represent positions and
directions. A position has a 1 in its last element, and a direction has a
0.
I say directions, the vectors are not necessarily normalized, so they
are "directions with magnitude".
Positions implicitly mean "the place you get to if you start at the
origin and add the 3D part of the vector".
Directions-with-magnitude are not implicitly based at the origin. You
can add a d-with-m to a position to get to a new position.
[a0, a1, a2, 1] + [m0, m1, m2, 0] = [b0, b1, b2, 1]
If we do this as a 4D vector add, the result ends up correctly with a 1
in the 4th element-- it's a position.
Other implementation conveniences arise from this approach-- you can use
the last column of a 4D matrix to represent a translation. Applying the
matrix to a vector will rotate and then translate positions, but will
just rotate and not translate d-with-ms, because the 0 in the 4th
element will select out the last column in the matrix multiply.
Using this system, you should be able to do everything with straight 4D
matrix arithmetic, and if you ever end up with a 2 or a -1, or anything
that isn't 0 or 1 in the 4th element of a vector, you've done something
wrong.
Adding two positions, for example, gives you a 2 in that 4th element.
And, thinking of it geometrically, it doesn't make a lot of sense
because positions are implicitly "translations from the origin", so you
can't translate one position from another position.
Well, we can represent time in a 1D space and use 2D "homogenous
coordinates":
[100, 0] means "100 seconds forwards"
[-100, 0] means "100 seconds ago"
[100, 1] means "100 seconds since 1970-01-01T00:00"
In exactly the same way we distinguish between a length of time, and a
length of time that implicitly starts at the origin.
start_date + (end_date - start_date) / 2
doesn't generate any invalid last-elements in any intermediate results,
but
(start_date + end_date) / 2
does.
In Python's datetime module, subtracting two dates returns a "timedelta"
object, which can be added to a date. But two dates cannot be added.
This seems a sensible way to do it, and if you wanted to do it in C++, I
think you'd overload global operators, not member function operators:
Timedelta& operator-(const Date& a, const Date& b);
Date& operator+(const Date& a, const Timedelta& delta);
Timedelta& operator+(const Timedelta& a, const Timedelta& b);
etc. You could make a perfectly usable system this way, and I'd say that
using operators for dates is no more or less sane or insane than using
them for matrices and vectors.
