Fixes for date handling, particularly around recurrence ranges.

[jimdunkerton]

No description provided.

[vboctor]

The removing of the unused imports and variables seems to be unrelated to this change. I would prefer if we have a pull request per bug as well.

I would rather hold off on pulling a new dependency until there is a bigger need for it. You can explain the reasoning over just fixing this bug using the standard jdk classes.

Feel free to open new pull requests or use this one to continue the discussion.

[jimdunkerton]

I do agree with the pull-request per bug. Issue #45 kind of depended on issue #43 being fixed, however, since if a recurrence range's start date can't be parsed, the parsing of the end date won't even take place, but I agree that they should be committed in separate PRs. However, they both depend on Joda-Time!

The reasoning around using Joda-Time to fix issue #43 is that a typical xs:date value may look something like this:

2002-09-24+06:00

as evidenced by the W3 page here:

http://www.w3schools.com/schema/schema_dtypes_date.asp

and, in fact, the value for the start and end dates of a recurrence range in the EWS API XML responses are presented in this format. Almost every other field that represents a point in time, according to the types.xsd, is presented as a date-time, as opposed to a date, and in most cases these are parsed successfully.

However, the basic java.util.Date API cannot seem to handle a whole date in the format specified by xs:date. This is just one of many deficiencies in that library. There is evidence for this problem here:

https://weblogs.java.net/blog/felipegaucho/archive/2009/12/06/jaxb-customization-xsddatetime

(Basically, the SimpleDateFormat class in Java's basic Date API doesn't like a colon in a timezone offset!)

and also in the exceptions that I've seen using a debugger (the stacktraces of which are not usually seen in logs or traces due to generally bad exception handling throughout the project).

Given that the xs:date is only used for three different fields - according to the types.xsd) - and the aforementioned lack of visilibity of exceptions, it is not too surprising that this issue may not have been caught before. Joda-Time, however, handles this case perfectly well, as well as many other cases, and its general use would lead to much reduced code particularly in the ExchangeServiceBase class.