Это определяется установленой TimeZone, конкретно её параметром DST. Не уверен, вышел ли уже патч на отмену перехода на летнее(или зимнее, не помню) время.
В качестве быстрого фикса я как-то раз подбирал зону UTC+4 без DST, результат совпадал с часами на стене. Но такой хак уберет переход вообще, то есть время в прошлом (когда переход еще имел место быть) может считаться ошибочно.

Поправил свой метод подсчета (который по историческим причинам носит название fastDiff ). Теперь он выдает результаты, приятные всем. Кроме того, не используются миллисекунды, а значит, перевод часов не должен портить результат, как в варианте с TimeUnit (или я неправ?)


Это сообщение отредактировал(а) Dummy - 11.1.2012, 16:17

Полностью согласен  . Вопрос, стоит ли дописывать в FAQ в статью про работу с датами?

Просто для сравнения приведу пример, как сделать тоже самое библиотекой Joda Time



Почувствуйте разницу)

Круто  Почему раньше не сказал? Мы же тут Calendar перепахали и в хвост и в гриву  Результат, вроде, такой же. Хотя по моим самопальным замерам Period все же работает помедленнее, чем наше коллективное творчество. Ну, да не суть. Про Joda Time до этого сам я только словеса слышал. И, вроде, планируют когда-нибудь даже включить ее в JDK: JSR-310. Но это уже совсем другая история.

Добавлено @ 00:30

Не знаю, часто ли бывает полезен полученный результат в других задачах, помимо расчета стажа  А так - информация может быть полезной, например, программистам мобильных JVM, которые, возможно, не захотят таскать за собой полметра Joda Time ради подобного подсчета.

Оффтоп: попытался плюсануть участникам дискуссии за полезный тред. Но что-то плюсовалка не работает...

Это сообщение отредактировал(а) Dummy - 12.1.2012, 01:11

Топикстартер хотел только стандартными средствами. Даже жирным шрифтом выделил в первом посте.



Не знаю, как именно Вы меряете, но с динамически компилируемыми языками не все так просто. У меня как раз завалялась хорошая статья по теме



Репутация на форуме совсем отвалилась: ни посмотреть, ни плюсануть(

Это сообщение отредактировал(а) jk1 - 12.1.2012, 10:29

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

Вывод организован так, чтобы при простом копировании в Excel получать внятную таблицу
Результаты сравнения
При началной дате 01.08.2008 Все результаты, кроме грубых совпали.
При начальной дате 02.08.2008 ошибка в выводе fastDiff для 01.08.2012: 29 дней 11 месяцев 4 года. Правильный ответ 30 дней 11 месяцев 3 года.
При начальной дате 02.08.2008 ошибка в выводе fastDiff для 1 и 2 августа 2012. Число дней на 1 меньше, а число лет на 1 больше.
При всех начальных датах до 29.08.2008 ошибка в выводе fastDiff для дней с 01 по дату начала-1 августа 2012. Ошибка та же.
Решил перепроверить последнюю версию fastDiff. Все точно. По крайней мере я ошибок не нашел. В чем глюк - не знаю.
При начальной дате 30.08.2008 число ошибок возрастает. неправильно подсчитано числ дней за все дни с 01.03.2012 по 29.03.2012 и с 01.08.2012 по 29.08.2012.
При начальной дате 30.08.2008 возникло одн разночтение между stag и Joda Time: 29.02.2012 stag вывел 30 дней 5 месяцев и 3 года, а Joda Time - 0 дней 6 месяцев и 3 года.
Что из этих ответов считать правильным весьма спорный вопрос.
При начальной дате 31.08.2008 fastDiff врет в числе дней во всех месяцах, которые короче 31 дня.
Разночтения между stag и Joda Time возникают в последний день каждого месяца, который короче чем 31 день.
Если разночтения между stag и Joda Time носят спорный характер, то с fastDiff нужно разобраться.
Вернусь с работы - попробую выяснить причину.

Знаю. Недавно читал вот такой замечательный материал: статья с JavaOne. Поэтому постоянно говорю, что мои подсчеты, скорее всего, грубоваты, хотя перед тестами я прогреваю JVM.

Спасибо за тщательность! Поковыряю код, как будет время.

Это сообщение отредактировал(а) Dummy - 12.1.2012, 11:18

Ага, что-то шаманят...

В одном месте был мой глюк - перепутал дни и годы   . 
Второе чудо - свойство Calendar при установке, например, 30 февраля. Он не ругается, но и не ставит   .
Чуть-чуть подшаманил код, теперь все работает одинаково, за исключением спорного момента по поводу 30 дней 2 месяцев 3 лет и 0 дней 3 месяцев 3 лет.
Вот окончательный код fastDiff

По поводу скорости. Сначала прочитал предложенные Вами статьи. Это оказывается одна статья.
Подготовил тестер вроде бы нормально. Проведу тестирование - напишу.

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


Это чудо называется lenience. Контролируется через Calendar.setLenient(). Когда lenient = true (для Calendar это значение по умолчанию), календарь автоматически пытается транслировать некорректные даты. Например, 35 декабря 2008 года будет переведено в 4 января 2009. А 31 февраля 2012 - во 2-е марта 2012. Естественно, в fastDiff() это приводило к сползанию месяцев и чисел и краху моего алгоритма в ряде случаев. Поэтому лучше явно выставить при таких расчетах Calendar.setLenient(false) для всех используемых календарей. Тогда при установке неправильной даты мы сразу получим IllegalArgumentException.

Это сообщение отредактировал(а) Dummy - 12.1.2012, 13:39

Подвел результаты теста на скорость.
Для разогрева JVM использовал предыдущий вариант сраввения расчетов по всем четырем методам за год run().
в качестве самого теста - следующий код speed().

Результат обработал статистически. Стандартное отклонение менее 2% от средней величины.
Расход времени на один расчет в мс:
robust    fastDiff    stage    joda
231    433    430    276
Так что по моим данным Joda Time работает на треть быстрее fastDiff и лишь чуть медленнее чем robust.
Так что выбор достаточно прост:
Если отклонение в пару дней роли не играет - используем грубый метод.
Если нужно быстро и точно - Joda Time
Если строгое ограничение - стандартные библиотеки и нужна точность - fastDiff.

Теперь видимо окончательно все.     

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

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

Время счета на моем буке составило 20 минут.
Дальше в MS EXCEL отсортировал вывод по первому полю и отделил выводы всех методов друг от друга.
Для результатов каждого метода выполнил следующую обработку:
1. Отсортировал по времени выполнения.
2. Выкинул самый маленький и самый большой результаты.
3. Для оставшихся 100 значений рассчитал среднее и стандартное отклонение
Собственно и вся обработка   
Каждого было по 102 штуки.

Mirkes, Вас не смущает, что формулы для расчетов стандартной ошибки и стандартного отклонения, реализованные в Excel, отличаются от традиционных русских формул, приведенных в учебниках?