¿Por qué se desaprobaron la mayoría de los métodos java.util.Date?

Question

Cuando observa el javadoc de la clase java.util.Date, la mayoría de los métodos están en desuso. ¿Por qué se hizo esto?

Answer 1

Bueno, por dos razones relacionadas. Fue una implementación muy pobre del concepto de Fechas y horarios y fue reemplazada por la clase Calendar.

La clase Calendar, aunque una mejora, deja mucho que desear también, por lo que para el trabajo serio de Fecha/Hora, todos recomiendan Joda-Time. Java 8 trae el nuevo java.time.* package, inspirado en Joda-Time, definido por JSR-310, y destinado a suplantar las antiguas clases de Fecha/Calendario.

Editar: En respuesta a la pregunta específica de por qué la implementación es pobre, hay muchas razones. JavaDoc lo resume de la siguiente manera:

Desafortunadamente, la API para estas funciones no era susceptible de internacionalización.

Además de esta deficiencia general (que abarca cuestiones como la falta de un componente de zona horaria, así como el formato de fecha que se maneja mejor en DateFormat y la incapacidad para tener una representación de calendario no gregoriano), hay son cuestiones específicas que realmente perjudicaron la clase Date, incluido el hecho de que el año se presenta en una desviación de 1900 del año de la Era Común.

Calendar tiene sus propios problemas, pero incluso tan pronto como JDK 1.1 era obvio que java.util.Date no iba a cortarlo. A pesar de que Calendar es discutible, la peor API de JDK, hasta la versión 7 se intentó intentar abordarla.

Answer 2

Están en desuso porque Fecha fue escrita lo más rápido posible en el día en que querían apresurar el JDK por la puerta.

Resulta que las fechas y los calendarios son duros. Entonces, crearon la clase Calendar, que pensó mucho más, para manejar las partes difíciles de trabajar con calendarios.

Desaprobaron los métodos de fecha y se delegaron en el calendario porque no deseaban cambiar el comportamiento de los métodos de fecha existentes y posiblemente interrumpir las aplicaciones existentes.

Answer 3

• Date es mutable
• Date no tiene soporte para zonas horarias

Este último llevado a ser reemplazado por Calendar. Y el anterior, combinado con la facilidad de uso-, conducir a la vez que se sustituye por Joda-Time/JSR-310 (java.time.* package)

Answer 4

No sé la razón oficial por la que ya no se utiliza, pero en lo que puedo decir GregorianCalendar y Joda-Time admiten operaciones en fechas, lo que significa que puede agregar, por ejemplo, un día a una fecha y tener su mes y año actualizados en consecuencia.

Por ejemplo, supongamos que desea calcular el día posterior a la fecha actual y hoy es el 31 de mayo; con java.util.Date, solo tiene getDays() +1, que devuelve 32, y debe saber que el mes actual no tiene 32 días; con GregorianCalendar o Joda.time, agregar un día al 31 de mayo da como resultado un objeto que representa el 1 de junio, ocultando la complejidad de su vista.

Answer 5

He aquí una buena respuesta directa de Oracle: http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html

Una pesadilla de larga data de los desarrolladores de Java ha sido el apoyo insuficiente a los casos de fecha y el uso del tiempo de los desarrolladores ordinarios.

Por ejemplo, las clases existentes (como java.util.Date y SimpleDateFormatter) no son seguras para subprocesos, lo que genera posibles problemas de simultaneidad para los usuarios, algo que el desarrollador promedio esperaría al escribir el código de manejo de fecha.

Algunas de las clases de fecha y hora también muestran un diseño API bastante pobre. Por ejemplo, los años en java.util.Date comienzan a las 1900, los meses comienzan en 1 y los días comienzan en 0, lo que no es muy intuitivo.

... java.util.Date representa un instante en la línea de tiempo -una envoltura alrededor del número de milisegundos desde la época UNIX- pero si llama a String(), el resultado sugiere que tiene una zona horaria, lo que causa confusión entre desarrolladores.