DGM.minus(Date, Date) is conspicuously missing

An implementation has been committed to the trunk (cs14095).

It includes (and is based on) minus(Calendar, Calendar). And I think the date arithmetic should be extended to include the full suite for Calendar.

I think this change is sensible and simple enough to move along into 1.6.

can you explain why Date-Date should return int and not Date? Is Date-Date the same as int-Date with new Date(int)-Date and the same as Date-int with Date-new Date(int) ?

The difference between dates is definitely not a date, it is a duration. In the DGM date arithmetic durations are all in integer days. In the TimeCategory arithmetic is done with millisecond precision TimeDuration, but that it entirely separate.

As the javadoc sez:

bDate = aDate + (bDate - aDate)

Just like with numbers.

The only missing operation in DGM for Date now is plus(int, Date) which ought to exist because addition is commutative. But I don't find the omission to big a deal.

What would be really nice would be to have java.util.Date and java.sql.Date coercion with Calendar so that we could just write methods for Calendar and then any casts needed in user code would be inserted as needed.

true: bDate = aDate + (bDate - aDate), but: bDate != (aDate + bDate) - aDate Not equal because bDate is a Date and aDate will cause the production of an int. So it can't be equal. Things about having number like arithmetics is good and nice, but usually you talk about elements from the same set and operations defined on elements on that set. Here you have two sets and projections from each set into the other... but in mathematics you would still use explicit, maybe isomorphic, functions... well, int>Date: new Date(int) is not really a isomorphism, because it is not bijective, as there are several Date instances, you would map to the same int... but that is not really important here I guess.

Anyway, what does duration-date say? date minus duration makes sense, but the other way? Not really for me. Well, not topic of this issue, date-date with the result of a duration makes sense to me. So no objection... only in the implementation... sql.Date is a subclass of Date and the logic in sql.Date is exactly the same as in Date.. doesn't make that the method for sql.Date obsolete?

As for the coercion... coercion means waht to you? automatic type conversion during for example a method call, or explicit type conversion using asType and/or a cast?

It is OK that Duration-Date doesn't make sense even though Date-Duration does because subtraction (unlike addition) it not commutative.

The Date(long) constructor takes a milllisecond date value in the 1970 epoch (the Unix epoch), not the int days duration used in DGM's date arithmetic. It is the same precision as the duration in TimeCategory, but still a different type than a duration (even if expressed as long milliseconds in a epoch).

If automatic conversions were supplied like they are for number system, then we could have a date system that unifies (or at least hides the mess) of Java's multiple date types. If an exact match isn't present, then a conversion is made. That would happen for method calls and assignments.

A starting step though would be to implement asType which seems like a no-brainer to me (I just tried it and see that it doesn't work).

The reason the DGM date methods specialize for java.sql.Date is so that they can return that type when doing arithmetic. This might be a trouble spot. If someone does CallableStatement.setDate("x", new Date('1/11/2008') + 7) then we'll wind up with a java.sql.Date even if we didn't start with one. The trouble might arise for folks who do stuff dynamically (using Object[] or somesuch) and we'ld give them a Calendar even though they started with java.sql.Date. But the java.sql stuff will deal with Calendar as well, so that is probably the right thing to do for dynamic folks.

As for why I provided the DGM.minus(java.sql.Date, java.sql.Date) specialization is I was just following what DGM already did and I was just trying to fill in the gap. From this further examination I can see that it is not needed in this case.

Merged to 1.6.

Merged to 1.5.