current - localdatetime java class
¿Hay alguna desventaja para usar Joda-Time? (7)
Quiero convencer al gerente de arquitectura para que incluya el jarrón Joda-Time en nuestro producto.
¿Conoces alguna desventaja al usarlo?
Creo que Joda-Time necesita ser constantemente actualizado debido a los archivos que incluye. Y eso es una desventaja. Tal vez yo estoy equivocado.
¿Podría darnos alguna aclaración sobre el tema?
El mayor problema que tuvimos al usar Joda Time fue con la integración con Spring y Tapestry, ya que ambos querían usar la fecha y hora incorporadas. Constantemente escribíamos wrappers en getters / setters para la fecha y la hora: o bien lo almacenabamos como Joda Time y un conjunto de getters / setters lo pasaba y el otro lo convertía sobre la marcha, y algunas clases lo almacenaban internamente como Java Fecha / Hora, y Joda getter / setter tuvo que cambiarlo sobre la marcha.
Básicamente, fue un dolor de cabeza porque las clases tienen un nombre similar, y a menos que pueda obtener toda su arquitectura (incluidas otras bibliotecas que está integrando) para cambiar a Joda Time, va a escribir más código de contenedor de lo que probablemente ahorrará mediante el uso de las bibliotecas Joda.
En el pasado, me he encontrado con empresas que no deseaban incorporar software de código abierto de terceros o, al menos, exigían que el abogado de la empresa certificara que la licencia no los expondría a ningún tipo de responsabilidad ni a tener una vulnerabilidad viral. efecto en su producto.
Al igual que con cualquier biblioteca de terceros, probablemente debería ponerlo en control de fuente para que pueda encontrar la versión que envió con versiones particulares de su código en caso de que algo salga mal.
He tenido experiencias casi totalmente positivas con Joda Time. Mi único problema fue cuando intenté construir mi propia zona horaria (por razones legítimas, te lo aseguro :) Obtuve algunas excepciones muy raras, y la documentación no era muy buena para ese caso de uso en particular.
Sin embargo, en su mayor parte ha sido un placer usarlo: la inmutabilidad hace que el código sea mucho más fácil de razonar, y la seguridad de los hilos para los formateadores es muy útil.
Sí, hay archivos para estar al día, pero al menos puede mantenerlos actualizados. No es que contengan cosas que eran innecesarias con las cosas integradas de Java, ¡es solo que con el mecanismo de Java simplemente no se puede mantener la información como zonas horarias actualizadas sin hacking significativo!
Básicamente, +1 para usar Joda Time. La API de fecha / hora de Java es uno de los peores bits de la plataforma Java, IMO.
La elección de milisegundos para el continuo de tiempo subyacente es buena para implementar calendarios de antigüedad y calendarios especiales. A diferencia de muchos contadores, el contador de milisegundos de 64 bits tiene una buena cobertura de rango para calendarios de antigüedad, con propiedades de renovación superiores a +/- 260 millones de años.
No maneja los segundos intercalares. Ésto es una cosa buena. Los cronometradores atómicos proponen una transición fluida para permitir que los sistemas que no implementan segundos intercalares ajusten incrementalmente sus relojes durante más de 100 segundos para acomodar la corrección del segundo intercalar.
El mantenimiento de las tablas de la zona horaria también será un problema.
El continuo subyacente también permite un antiguo calendario francés y un reloj que divide un día en 10 intervalos llamados tiempo métrico en lugar de 24 horas. El calendario chino clásico divide un día en 100 incrementos, cada uno con más de 14 minutos de duración. Todos estos calendarios se pueden implementar y coordinar en el continuo de tiempo en milisegundos subyacente.
Parleys presenta una presentación de Stephen Colebourne sobre JSR-310 , el Sr. Colebourne, autor de Joda-Time y JSR-310. Comienza explicando las debilidades del soporte estándar de fecha / hora en Java y por qué querría usar una alternativa. Puede ser útil mostrar esta presentación a su administrador de arquitectura. Parece que no puedo hacer un deep-link
La razón por la que Joda-Time actualiza su archivo de zona horaria con bastante frecuencia es porque los datos de la zona horaria cambian todo el tiempo, a menudo con poca antelación (hoy en slashdot: segundo bis el 2008-12-31 ) y no siempre motivados científicamente (por ejemplo, recuerdo algunos pacíficos el estado de la isla cambió su zona horaria para ser el primer país en ingresar al año 2000).
El problema principal es el bloqueo de proveedor al menos hasta que se convierta en parte del estándar.
En su mayor parte usaría largos para almacenar cualquier información de fecha de negocios en una base de datos. Esto me da la flexibilidad de ajustar la precisión como mejor me parezca. En la mayoría de los casos, simplemente los convierto en java.util.Date.
Las zonas horarias que trataría serían un problema de nivel de presentación más que un problema de datos. Esto simplifica la base de datos y aumenta la portabilidad ya que las bases de datos pueden representar temporales de diferentes maneras.
La clase de calendario estándar me proporciona algunas funciones de manipulación de fechas que convierto en milisegundos a partir de datos de época.
En cuanto a la precisión de nanosegundos, almacenaría eso como un desplazamiento desde 0 como una columna larga separada.
En mi opinión, el inconveniente más importante en Joda-Time es la precisión: muchas bases de datos almacenan marcas de tiempo con precisión de microsegundos (o incluso nanosegundos ). Joda-time va solo a milisegundos . Esto no es aceptable para mí: todas las clases de "modelos de datos" que utilizo necesitan reflejar la precisión total de los datos en mi base de datos. Las aproximaciones o truncamientos de mis datos por una biblioteca simplemente no lo cortan.
Aquí está el razonamiento detrás de la elección de la precisión en milisegundos, tomada de la lista de correo JSR 310 :
"Joda-Time eligió utilizar milisegundos, ya que facilitaba las conversiones a la fecha y al calendario". - S. Colebourne
¿Más fácil para quién? El autor de la biblioteca, uno asumiría ... Decisión de diseño incorrecta, en mi opinión, cuando casi todas las bases de datos almacenan tiempos a microsegundos / nanosegundos de precisión. La indiferencia por los valores de la base de datos es preocupante.