Antes de escribir una fecha de Java en una columna SQL TIMESTAMP, ¿JDBC traduce la fecha de la zona horaria de la JVM a la zona horaria de la sesión de la base de datos?

Question

Antes de escribir un Java Date en una columna SQL TIMESTAMP, ¿JDBC traduce la fecha de la zona horaria de la máquina virtual Java a la de la sesión de la base de datos?

Por ejemplo, supongamos que la zona horaria de la máquina virtual Java es UTC y la zona horaria de la sesión de la base de datos es UTC-5. Si un programa Java intenta almacenar 2000-01-01 00:00:00 pasándolo a PreparedStatement#setTimestamp(int, Timestamp), de acuerdo con el estándar JDBC, ¿almacenará la base de datos TIMESTAMP '2000-01-01 00:00:00' o TIMESTAMP '1999-12-31 19:00:00'?

Answer 1

No, JDBC es solo una API sobre cómo el cliente puede acceder a la base de datos. Para el almacenamiento de marca de tiempo, esto tendrá que ser dependiente de la organización que escribe sus controladores de base de datos que cumplen con el estándar API de JDBC.

Here's una implementación de la implementación de MySQL de PreparedStatement. Parecen tomar la zona horaria JVM de Java a la zona horaria de MySQL (consulte el método setTimestampInternal()).

Answer 2

Ahora mi requisito es que debe almacenar el valor en GMT/UTC independientemente de la zona horaria de la JVM. ¿Hay alguna manera de configurar la zona horaria sobre la marcha y luego desarmarla una vez que haya terminado con JDBC?

Edit: Bien, encontré una manera de evitar ese problema. Lo hicieron los siguientes

TimeZone default = TimeZone.getDefault(); 
try 
{ 
    TimeZone.setDefault(TimeZone.getTimeZone("UTC")); 

    //Do stuff with JDBC 
} 
finally 
{ 
    TimeZone.setDefault(default); 
} 

Answer 3

usted puede utilizar sobrecargados setTimestamp setter aceptar Calendar ejemplo, para especificar la zona horaria

muestra (Si está utilizando Joda de fecha y hora):

org.joda.time.DateTime sendDateUTC = new DateTime(DateTimeZone.UTC).withMillis(millis); 
statement.setTimestamp (1, sendDateUTC, sendDateUTC.toGregorianCalendar()); 

Según Javadoc: Conjuntos el parámetro designado para el valor dado java.sql.Timestamp, utilizando el objeto Calendar dado. El controlador utiliza el objeto Calendar para construir un valor SQL TIMESTAMP, que luego el controlador envía a la base de datos. Con un objeto Calendar, el controlador puede calcular la marca de tiempo teniendo en cuenta una zona horaria personalizada. Si no se especifica ningún objeto de calendario, el controlador utiliza la zona horaria predeterminada, que es la de la máquina virtual que ejecuta la aplicación.

void setTimestamp(int parameterIndex, java.sql.Timestamp x, Calendar cal) 
    throws SQLException; 

Answer 4

La especificación es ridícula. Java.util.Date almacena milisegundos de época en el marco de referencia GMT. Java.sql.Timestamp es una fecha más nanosegundos en el mismo marco de referencia. Todos los get y depreciadores no en desuso utilizan el marco de referencia GMT. Para cualquier tipo de cordura, la zona horaria predeterminada para almacenar una marca de tiempo debe ser GMT.

En una aplicación de varios niveles, el servidor de aplicaciones para el usuario, el controlador y el servidor de la base de datos podrían estar en distintas zonas horarias. Algunos de los niveles pueden estar en diferentes zonas horarias al mismo tiempo; por ejemplo, si está equilibrando la carga de Internet en un continente, o si tiene una aplicación móvil que se conecta a un servidor central. Un entorno operativo en la nube sería prácticamente el mismo escenario en el que no tienes idea de dónde se ejecutará el controlador JDBC, ni ninguna garantía que nunca cambie.

La única forma que conozco de lograr consistencia en estos entornos es usar solo el parámetro setter y ResultSet getter que aceptan un calendario, y asegurarse de que cada aplicación que accede a los datos use algún calendario, preferiblemente GMT o UTC.