Este post es viejo, pero me parece que la línea en la solución aceptada un poco larga y no encontré nada mejor en lo que existe. Así que hice una pequeña clase que lo envuelve de Fecha y Tiempo:
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);
}
lo que esta línea:
new Duration(date.getTime(), System.currentTimeMillis()).isShorterThan(Duration.standardSeconds(5)
se convierte en:
DateUtils.dateIsCloseToNow(date, Duration.standardSeconds(5))
encontré que realmente útil en los casos de prueba de unidad donde necesitaba validar una fecha de creación.
Parece bastante práctico. Mi única crítica es pequeña, sobre nombrar: cambiaría el nombre de 'fecha ...' a 'fecha y hora ...' (como 'datetimesAreEqual' en lugar de 'fechasAreEqual'), solo para evitar confusiones con el mal llamado 'java .util.Date' y con 'LocalDate'. También podría decir 'AreClose' en lugar de 'AreEqual' y 'IsCloseToNow' en lugar de 'IsNow'. –
"IsClose" podría ser más claro de hecho. Para DateTime, no estoy seguro. Dado que los métodos toman como parámetros Date y DateTime, creo que Date es más claro. Aunque, la clase podría cambiarse a DateTimeUtils. Editaré la publicación. – FredBoutin