Cómo utilizar Joda-Time con java.sql.Timestamp

Question

Tengo un declaración preparada

INSERT INTO mst(time) VALUES (?);

donde el tiempo es de tipo Marca de tiempo en un PostgreSQL base de datos.
estoy insertando un Tiempo Joda Fecha y hora objeto, o debería decir que lo estoy intentando.No puedo encontrar ninguna manera de convertir el objeto DateTime en un java.sql.marca de tiempo.He leído los documentos de Joda-Time y no veo ninguna referencia a esto.

Gracias.

Answer 1

Puede convertir un DateTime Joda a unas largas (en milisegundos desde la época) en primer lugar, y luego crear una marca de tiempo de eso.

DateTime dateTime = new DateTime();
Timestamp timeStamp = new Timestamp(dateTime.getMillis());

Answer 2

El constructor DateTime de JodaTime puede manejar esto por usted ahora.(No estoy seguro de si eso era cierto cuando se publicó la pregunta, pero es uno de los mejores resultados de Google, así que pensé en agregar una solución más nueva).

Hay algunas opciones de API:

public DateTime(Object instant);
public DateTime(Object instant, DateTimeZone zone);

Ambas opciones aceptan java.sql.Timestamp porque extiende java.util.Date, pero los nanosegundos se ignorarán (se limitarán), porque DateTime y Date solo tienen una resolución de milisegundos*.Sin una zona horaria específica, el valor predeterminado será DateTimeZone.UTC.

<Modo didáctico>
"Resolución" es la cantidad de dígitos que se proporcionan."Precisión" es qué tan precisa es la representación.Por ejemplo, DateTime de MSSQL tiene una resolución de milisegundos, pero solo ~ 1/3 de segundo de precisión (DateTime2 tiene resolución variable y mayor precisión).
</Modo Didáctico>

Ejemplo de marca de tiempo UTC con resolución de milisegundos:

new DateTime(resultSet.getTimestamp(1));

Si está utilizando TIMESTAMP CON ZONA HORARIA en su base de datos, entonces no puede usar java.sql.Timestamp porque no admite zonas horarias.Tendrás que usar ResultSet#getString y analizar la cadena.

Marca de tiempo sin zona horaria con segundo ejemplo de resolución**:

LocalDateTime dt = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss")
    .parseLocalDateTime(resultSet.getString(1));

Ejemplo de marca de tiempo UTC con segunda resolución**:

DateTime dt = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss")
    .parseDateTime(resultSet.getString(1));

Marca de tiempo con zona horaria (formato de compensación) con segundo ejemplo de resolución**:

DateTime dt = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss Z")
    .parseDateTime(resultSet.getString(1));

Prima:DateTimeFormat#forPattern almacena en caché estáticamente los analizadores por patrón para que usted no tenga que hacerlo.

<Modo didáctico>
Generalmente recomiendo usar un String en su modelo DBO para hacer explícita la resolución y evitar generar objetos intermedios.(¿Es 2013-11-14 09:55:25 igual a 2013-11-14 09:55:25.000?) Generalmente trato de distinguir entre "objetos de modelo de base de datos" que se optimizan para cuestiones de preservación de datos y "objetos de modelo de negocio" que se optimizan para uso del nivel de servicio con una capa de transformación/mapeo en el medio.Creo que tener DAO basados ​​en CRUD que generan objetos comerciales directamente tiende a mezclar las prioridades y no optimizar ninguna de las dos, generando excepciones desde lugares inesperados debido a casos extremos omitidos.Tener una capa de transformación explícita también le permite agregar validación si es necesario, como si no controlara la fuente de datos.Separar las preocupaciones también hace que sea más fácil probar cada capa de forma independiente.
</Modo Didáctico>

* Si necesita resolver la resolución de nanosegundos en su modelo de negocio, tendrá que utilizar una biblioteca diferente.

** El formato de la cadena de marca de tiempo puede variar entre bases de datos, no estoy seguro.