Существуют ли стандартные (встроенные в JRE) классы, объекты и методы, которые позволят рассчитать количество лет, месяцев, недель и дней между двумя датами по грегорианскому календарю?
По юлианскому календарю?

Это как бы основа

А конкретный тип календаря определяется конкретным наследником java.util.Calendar. Например там есть GregorianCalendar.

jk1, меня больше интересует не общее количество дней, а количество лет, месяцев, недель и дней между двумя датами.

arcsupport, можно примерно так





Оно?

Добавлено через 5 минут и 2 секунды
Года не добавлял, т.к. они могут быть високосные и невисокосные. Если это не важно, то в массив MILILIS можно добавить на первое место еще одну константу MILLIS_PER_YEAR = 355 * MILLIS_PER_DAY; и в MessageFormat.format("{0} days, {1} hours, {2} minutes", res);  добавить {0} years

Не надо изобретать велосипедов. Класс TimeUnit, о котором я говорил выше, умеет выполнять преобразования единиц времени. В данном случае это будут преобразования милисекунд в минуты, часы, дни.

Преобразование он делать умеет, а вот делить с остатком - нет

Умеет



дает в результате 1

А остаток?

Вуаля

По моему умудренные советчики не поняли вопроса. Вопрос в исчислении стажа того или иного вида. То есть следует указать сколько лет, месяцев и дней прошло от одной даты до другой.
Нельзя говорить 100 дней, нужно сказать три месяца и ? дней.
С этого момента начинаются неприятности при подсчете стажей, поскольку разные месяцы содержат разное число дней.
Далее вопрос о том, какая точность нужна.
Ниже пример для грубого подсчета без делений, а средствами стандартных библиотек.
Еще ниже (по тексту)  пример точного подсчета. Текст не оптимизирован. Если задача регулярная, то стоит написать отдельную функцию и почистить код.

пример вывода 
1257                                      вариант jk1 - просто число дней.
11 days 5 month 3 years         грубый расчет.
9 days 5 month 3 years           точный расчет

Забавно, но куда-то потерялось два дня. Я думал что разность будет в один день.

Mirkes, спасибо.

Mirkes, в вашей реализации я вижу пару моментов, с которыми хочется поспорить.

•  Перемотка календаря past на один месяц назад/вперед может привести к накоплению погрешности по дням. Скажем, 30-е марта при перемотке месяца назад превратится в 28/29 февраля. Насколько это чревато, я не разбирался 
•  Постоянное использование Calendar.add() - это удар по производительности, т. к. внутри календаря может производится множество пересчетов. Насколько велика будет потеря в производительности, зависит от конкретной реализации Calendar.

И в целом - подсчет с использованием Calendar.add() не приводит к универсальной работе с календарями, в которых переменное количество месяцев в году (не знаю, применяются ли где-нибудь такие). Соответственно, нет смысла ее использовать. Для календарей с фиксированным количеством месяцев, к которым относятся григорианский и юлианский, разницу можно посчитать руками. Я тут набросал такое:

На моей машине и с моим самопальным тестом (не претендующим на особую прецизионность), скорость вычисления увеличивается раза в полтора-два.

Это сообщение отредактировал(а) Dummy - 10.1.2012, 22:12

Есть подозрение, что вот этот фрагмент внесет погрешность. К сожалению пора на работу и нет времени проверить. Как только буду готов - напишу.
По поводу эффективности алгоритмов - я уже написал, что алгоритм не оптимизирован.
Успел набросать на основе метода Dummy свой метод.

Нужно провести тест для проверки возникновения различий.
Разница точно возникла, но мое время истекло. Вернусь - проверю что правильно.

Принял экзамен, теперь можно сдавать экзамен на владение датами.
В ходе ряда экспериментов установил, что пользоваться функцией TimeUnit.DAYS.convert для вычисления числа дней надо предельно акуратно, поскольку она имеет дурную привычку учитывать переоз на зимнее/летнее время, даже если его не было. Или перевод времени можно отключить?
Сравнение  FastDiff Dummy, и моего stag в следующей редакции:

Сравнение производилось следующим способом.
Начальная дата выбиралась и задавалась вручную.
В качестве конечной даты рассматривались все даты начиная с 11.01.2012 в течении 370 дней - чуть больше года.
Все совпало при дате начала 01.08.2008.
Различия установлены в следующих случаях:
стартовая дата 02.08.2008
отличия в случаях (плюс по одному случаю совпадения)
Дата конца              FastDiff Dummy            Мой stag
29.02.2012    27 days 6 month 3 years    27 days 6 month 3 years
01.03.2012    30 days 6 month 3 years    28 days 6 month 3 years
02.03.2012    0 days 7 month 3 years    0 days 7 month 3 years

30.04.2012    28 days 8 month 3 years    28 days 8 month 3 years
01.05.2012    30 days 8 month 3 years    29 days 8 month 3 years
02.05.2012    0 days 9 month 3 years    0 days 9 month 3 years

Дальше видимо можно не продолжать.
Вопрос о том, что есть правильно, конечно спорный, но вывод моего метода мне гораздо приятней.
Если это нужно, то описание расчетов разницы дат можно добавить в статью по работе с датами в Java в FAQ

И в изначальном варианте не мог быть оптимизирован. Кроме того, выдавал отрицательное количество месяцев на некоторых данных.


Cогласен  Ваш второй метод выдает более разумный результат, чем мой, т. к. логичнее считать количество дней по последнему не полностью доработанному месяцу.