Con el motivo de la adición del JSR 310, "Date and Time API", a la lista de características oficiales que estarán soportadas en Java 8, InfoQ ha publicado un pequeño resumen de la historia de lo que probablemente sea la metedura de pata más grande de los APIs estándar Java: java.util.Date. Os dejo aquí un resumen de esa historia, completando algunos aspectos.
Todo empezó en 1995 con la primera versión de Java, 1.0. java.util.Date pasó a formar parte del paquete que, junto con java.lang, pueden considerarse el conjunto de clases más core de todo el API estándar. La elección de la representación temporal, un campo numérico que contenía tanto información acerca del día como de la hora, no fue muy acertada, sobre todo por lo complicada que es de internacionalizar. Además, el API tenía un comportamiento bastante confuso. Los meses y las horas comienzan a contar en "0", pero los días comienzan a contar en "1". Y los años comienzan a contar en "1900". Eso a pesar de que el campo encapsulado por java.util.Date cuenta el offset en milisegundos a partir del 1 de Enero, 1970 00:00:00.000 GMT, por lo que si representamos fechas anteriores a este año se representarán por un valor negativo.
Para terminar de rematar la faena, los objetos java.util.Date son mutables, por lo tanto propensos a problemas de multithreading y en estos escenarios a menudo es necesario estar haciendo copias de ellos todo el tiempo.
En 1997 con Java 1.1 se añadió soporte para SQL. Y con este soporte se añadió la clase java.sql.Date, que hereda de java.util.Date, pero a pesar de que un java.sql.Date es un java.util.Date la clase tiene un propósito diferente: sólo representa fechas, no horas, minutos o seguntos. Por lo que pone a cero las horas, minutos, segundos y milisegundos de java.util.Date. Y para incrementar todavía más la confusión, hay un segundo wrapper para java.util.Date que también hereda de él, java.sql.Timestamp, que si que tiene horas, minutos, segundos y nanosegundos (no milisegundos). Obvio.
En 1998 IBM contribuyó una clase que pretendía reemplazar a java.util.Date: java.util.Calendar. Tenía un soporte de internacionalización más aceptable, y era muy flexible. Demasiado. Tanto que incluso hacer tareas sencillas con ella puede ser bastante complejo.
Este es el contexto que llevó a Stephen Colebourne a publicar en 2005 su librería alternativa para trabajar con fechas en Java: Joda-time. La librería era una mejora significativa respecto a las API estándar, y pronto ganó popularidad. Pero no dejaba de ser una librería externa que proporcionaba una funcionalidad que debía formar parte del core de la plataforma. Por ello en enero de 2007 se crea un JSR para, inspirándose en Joda-time, estandarizar esta librería e incorporarla a la plataforma.
Debería haber sido parte de Java 7, pero el derrumbamiento de Sun en sus últimos años de existencia, junto con las circunstancias en general, conspiraron para que no estuviese lista. Ahora, por fin, en 2012 ha sido añadida como característica que estará presente en Java 8, y acaba de comenzar el trabajo de integración en OpenJDK. En octubre de 2013 se liberará Java 8, y por fin, casi 20 años después, tendremos un API decente para trabajar con fechas.