nueva - time java ejemplo

¿Por qué no debería usar date4j en lugar de joda java.util.Calendar o jsr 310?

Question

Hace poco me encontré con date4j , una biblioteca extremadamente simple (esencialmente una sola clase) para trabajar con fechas en Java. Conceptualmente, me gusta mucho la "idea" de date4j. De hecho, después de leer todo el sitio principal y la documentación en el javadoc, estoy bastante de acuerdo con todo lo expuesto.

Ahora, puede haber varias razones por las que no debería usar date4j: errores, rendimiento, falta de usuarios, etc. No pregunto por esas cosas. Estoy preguntando, conceptualmente, ¿qué hay de malo con la idea de date4j (para la mayoría de las aplicaciones)? Seguramente, puede haber algunas aplicaciones que necesiten algo como joda o threeten, pero creo que esas son minorías.

El consejo habitual que la gente da a los usuarios que tratan fechas / horas (casi todo el mundo que escribe una aplicación java) es algo así como:

• Use joda-time en lugar de java.util.Calendar
• Configure su servidor web a UTC
• Configure su servidor de base de datos a UTC
• Almacena tu fecha y hora en UTC

De hecho, los últimos tres puntos ilustran los problemas con el modelo mental actual que tienen las personas cuando trabajan con fechas. Las personas intentan administrar las zonas horarias tanto a nivel de la aplicación como de la base de datos (sin mencionar que los marcos ORM agregan otra capa de abstracción que complica aún más las cosas).

No deberías tener que hacer esas cosas. Si está utilizando java.util.Calendar, por ejemplo, y está manipulando un tiempo en alguna zona horaria definida por el usuario:

Calendar c = Calendar.getInstance(TimeZone.getTimeZone("America/New_York"));
c.set(Calendar.YEAR, 2011);
c.set(Calendar.MONTH, 0);
c.set(Calendar.DAY_OF_MONTH, 1);
c.set(Calendar.HOUR_OF_DAY, 3);
c.set(Calendar.MINUTE, 0);
c.set(Calendar.SECOND, 0);
c.set(Calendar.MILLISECOND, 0);

Esto representa un "instante" en el tiempo independientemente de la zona horaria. Debería poder persistir este tiempo hacia y desde la base de datos sin preocuparse de que se produzcan "conversiones". No importa si la base de datos está en la zona horaria de Shanghai y el servidor web está en la zona horaria de Los Ángeles: el instante en el tiempo es el mismo, independientemente.

Un problema es que algunas bases de datos intentan administrar las zonas horarias por usted (¡lo estoy viendo, Postgres! Grr!) Y para empeorar las cosas, el comportamiento en el nivel del controlador JDBC es específico del proveedor , es decir, PreparedStatement.setDate / getDate.

El modelo mental que usa date4j parece deshacerse de toda la confusión. Por ejemplo, forzar explícitamente los usos para proporcionar una zona horaria al llamar ahora (). Hay algunas recomendaciones muy buenas en el sitio para usar la biblioteca (estas cosas ya las estaba haciendo en mi propia aplicación anteriormente), tales como:

• no utilice un tipo de base de datos que intente administrar las zonas horarias
• almacenar la zona horaria como una columna separada (si es necesario)

¿Por qué no hay más gente adoptando una biblioteca como date4j?

Answer 1

Han pasado cuatro años y me he encontrado con esta pregunta. Para mí, el problema # 1 con date4j es errores. Sé que específicamente no preguntaste sobre eso, pero es un problema importante.

Más específicamente, los errores en sí mismos no son un problema por sí mismos, es la ausencia total de algún tipo de sistema de informe de errores lo que me molesta acerca de date4j. Ni siquiera hay una lista de correo, que yo sepa, no hay nada en absoluto. Sé que esto probablemente no sea muy interesante para una discusión sobre cómo debería ser la API de fecha / hora, pero aún así, la infraestructura es importante.

La falta de uno puede muy bien ser una razón por la cual una biblioteca no se adopta ampliamente.

Answer 2

Nunca he visto date4j hasta ahora, pero leí la documentación y tengo un problema concreto y una opinión sobre lo que está mal.

Primero, el problema concreto. No mantiene Timezone internamente. Así que hay ambigüedad sobre el horario de verano. Considere la transición del domingo cuando 1:59:59 am (EDT) se convierta en 1:00:00 am (EST). Claramente, en ese día, decir 1:30 am es ambiguo. Ese tiempo pasa dos veces. Así que lo siguiente es ambiguo.

new DateTime("2011-11-06 01:30:00")

En segundo lugar, mi opinión. El problema con la fecha era que no mantenía la Zona horaria. Cuando llegó el calendario, el daño ya estaba hecho. Además, el Calendario en sí mismo no se hizo ningún favor al ser mutable. Pero en el fondo, la solución tiene que incluir no solo el momento, sino también el lugar donde se percibió: zona horaria, cultura, tipo de lugar. Entonces, estos deben mantenerse junto con el momento en que se conservan en la base de datos, se serializan, se comunican, lo que sea. Este mismo principio personal me hace sugerir humildemente que incluso xsd: dateTime se queda corto porque simplemente permite que una fecha y hora se expresen en relación con UTC, no tiene disposiciones para proporcionar si, por ejemplo, se estaba observando el horario de verano.