



Мне любопытно услышать, что другие люди говорят об этом. Мой собственный опыт показывает, что сокращение пути (например, «лучшие или более разумные идеи») с Date почти всегда приводит к неприятностям. Черт возьми, просто использование java.util.Date вызывает проблемы.
Добавлено: многие рекомендовали Джода Тайм в других темах, связанных с датами.
Ярлыки почти всегда игнорируют влияние часового пояса, перехода на летнее время, високосного года, секунды координации и т. д. Например, то же время, что и сейчас, завтра не обязательно сейчас + 86400 секунд.
Кроме того, я добавлю, что ошибки, связанные с эффектами TZ, DST и т. д., Представляют собой гнусные типы ошибок, которые легко ускользнуть от отдела контроля качества. В качестве доказательства рассмотрим, как в мире java.util.Date превратился в Java 1.0 со всеми проблемами, связанными с TZ.
Я бы подумал об использовании предопределенного API как умного способа сделать это.
Не знаете, почему бы вам просто не использовать объект Calendar? Это просто и удобно. Я согласен не использовать Date, почти все полезное в нем устарело. :(
Я использую метод грубой силы
// make it now
Calendar dateCal = Calendar.getInstance();
// make it tomorrow
dateCal.add(Calendar.DAY_OF_YEAR, 1);
// Now set it to the time you want
dateCal.set(Calendar.HOUR_OF_DAY, hours);
dateCal.set(Calendar.MINUTE, minutes);
dateCal.set(Calendar.SECOND, seconds);
dateCal.set(Calendar.MILLISECOND, 0);
return dateCal.getTime();
dateCal.setTime (new Date ()) является избыточным. Calendar.getInstance () возвращает календарь, который «основан на текущем времени в часовом поясе по умолчанию с локалью по умолчанию».
Не забывайте приводить примеры того, почему это доставляет вам неприятности.