bài này là cũ, nhưng tôi tìm thấy những dòng trong các giải pháp chấp nhận một chút dài và tôi thấy không có gì tốt hơn trong những gì tồn tại. Vì vậy, tôi đã làm một lớp nhỏ mà kết thúc tốt đẹp cho ngày và DateTime:
public class DateTimeUtils
{
public static boolean dateIsCloseToNow(Date dateToCheck,
Duration tolerance)
{
return dateIsCloseToNow(new DateTime(dateToCheck), tolerance);
}
public static boolean dateIsCloseToNow(DateTime dateToCheck,
Duration tolerance)
{
return datesAreClose(dateToCheck, DateTime.now(), tolerance);
}
public static boolean datesAreClose(Date date1,
Date date2,
Duration tolerance)
{
return datesAreClose(new DateTime(date1), new DateTime(date2), tolerance);
}
public static boolean datesAreClose(DateTime date1,
DateTime date2,
Duration tolerance)
{
if (date1.isBefore(date2)) {
return new Duration(date1, date2).isShorterThan(tolerance);
}
return new Duration(date2, date1).isShorterThan(tolerance);
}
nên dòng này:
new Duration(date.getTime(), System.currentTimeMillis()).isShorterThan(Duration.standardSeconds(5)
trở thành:
DateUtils.dateIsCloseToNow(date, Duration.standardSeconds(5))
tôi thấy rằng thực sự hữu ích trong trường hợp kiểm tra đơn vị nơi tôi cần xác thực ngày tạo.
Trông khá tiện dụng. Lời chỉ trích duy nhất của tôi là nhỏ, về cách đặt tên: Tôi sẽ thay đổi cách đặt tên từ 'date ...' thành 'datetimeimes' (chẳng hạn như 'datetimesAreEqual' thay vì 'datesAreEqual'), chỉ để tránh nhầm lẫn với mis 'named' java .util.Date' và với 'LocalDate'. Tôi cũng có thể nói 'AreClose' thay vì 'AreEqual' và 'IsCloseToNow' thay vì 'IsNow'. –
"IsClose" có thể rõ ràng hơn. Đối với DateTime, tôi không chắc chắn. Vì các phương thức đều lấy Date và DateTime làm tham số, tôi nghĩ Date là rõ ràng hơn. Mặc dù, lớp có thể được đổi tên thành DateTimeUtils. Tôi sẽ chỉnh sửa bài đăng. – FredBoutin