and if that “next day” involves end of month and end of year dates, the error is magnified.
That's only an issue if you include a day, in which case a month should be added. In any other case, tomorrow is tomorrow - month or year boundaries have no effect. Unless, of course, this function is implemented by a heroic programmer who thinks they can come up with this themselves; lazy programmers like me just do "dateObject.add(Calendar.DAY, 1)".
The new API requires us to send a full, valid date string, not DTG. (e.g.: '2012-10-29T10:43:00.000') Since we still want to accept DTG in NAIPS for iPhone, that means we have to parse this and take care of this roll-over handling ourselves.