Tiempo en un entorno replicado

Los siguientes comportamientos se aplican a los tipos temporales NPS y su manejo:

• Los tipos de datos temporales Netezza® (DATE, TIME y TIMESTAMP) almacenan valores de fecha, hora y marca de tiempo que no reflejan la zona horaria en la que se generaron.
• Se aceptan todos los literales legales de fecha, hora y fecha-hora de una sesión SQL.
• Las funciones SQL CURRENT_DATE, CURRENT_TIME y CURRENT_TIMESTAMP (también NOW) generan valores de fecha, hora y fecha-hora que reflejan la hora en la zona horaria actual. La zona horaria actual, por defecto, es la del host del servidor NPS. Puede anular esta zona horaria en una sesión SQL utilizando el comando SET TIME ZONE o, de forma equivalente, el comando SET TIMEZONE. Afecta a los valores que se generan cuando esa sesión llama a las tres funciones. Incluso en un único host Netezza, no tiene ninguna garantía de que los valores de fecha, hora o fecha-hora que se insertan desde diferentes sesiones de cliente (o la misma sesión, con diferentes configuraciones del comando SET TIME ZONE ) tengan alguna referencia de fecha-hora o zona horaria común.
• La aplicación debe gestionar si la interpretación de la zona horaria es relativa a los valores de fecha, hora y tiempo de las columnas de la tabla.
• Algunas herramientas incorporadas para manejar la información sobre la hora y la zona horaria incluyen el tipo de datos TIMETZ (un alias para el tipo de datos TIME WITH TIME ZONE) y la función TIMEZONE(). TIMETZ es un tipo de dato temporal ligeramente diferente, ya que los valores llevan un desfase de zona horaria, que puede especificar en literales TIMETZ (por ejemplo, '01:23:45-06'). Si en una columna TIMETZ se inserta un literal similar a la hora sin el desfase horario, Replication Services utiliza '+00' (GMT).

El siguiente ejemplo ilustra las zonas horarias utilizando un entorno de replicación Netezza de dos nodos en el que el nodo primario está en Nueva York, EE.UU. (zona horaria Este), y el nodo de réplica está en Londres, Reino Unido (GMT). La siguiente fila de pedido se crea en el nodo NPS primario de Nueva York y se replica en la réplica de Londres. En este ejemplo, la marca de tiempo actual es el 19 de enero de 2012 a las 9:12 AM.

INSERT INTO ordertable values (1, current_timestamp, 'Product A');

La fila de la tabla en el nodo NPS primario aparecería de la siguiente manera:

ORDERNUMBER |   ORDERTIMESTAMP    | ORDERDETAILS
------------+---------------------+--------------
          1 | 2012-01-19 09:12:06 | Product A

Las diferencias horarias pueden afectar a las aplicaciones de informes que se ejecutan en el nodo NPS de réplica. Por ejemplo, como se muestra en el ejemplo anterior, pueden añadirse nuevos datos a la base de datos que parezcan ser de hace varias horas. Además, se introducen problemas adicionales si se invierten los papeles de los dos nodos NPS (Londres es ahora el primario y Nueva York es ahora la réplica). En ese caso, habrá filas con marcas de tiempo del futuro relativas a la réplica.

Existen varios métodos para compensar las diferencias horarias. La solución correcta depende de sus aplicaciones y su entorno.

• Haga que todas las horas sean relativas a una base común (por ejemplo, UTC o GMT).
• Capture información específica de la zona horaria siempre que se registre la hora.
• Capturar información de localización, ubicación o sistema para todos los registros (por ejemplo, en una columna Ubicación y una tabla de información de ubicación independiente).

Estos enfoques se describen en las secciones siguientes.

En el ejemplo anterior, las aplicaciones establecerían la variable de sesión TIMEZONE en cada nodo a GMT antes de realizar las operaciones DML:

SYSTEM(ADMIN)=> SET TIMEZONE='GMT';
SET VARIABLE
SYSTEM(ADMIN)=> show timezone;
NOTICE: Time zone is GMT
SHOW VARIABLE

La misma sentencia INSERT de la sección anterior registraría ahora la hora actual relativa a GMT:

ORDERNUMBER |   ORDERTIMESTAMP    | ORDERDETAILS
------------+---------------------+--------------
          1 | 2012-01-19 14:12:06 | Product A

Por ejemplo, una aplicación de elaboración de informes del ejemplo anterior tendría que ser consciente de los diferentes tiempos de funcionamiento relativos de las dos regiones. Una consulta para mostrar "todos los pedidos de hoy" tendría que tener en cuenta qué es "hoy", en relación con las distintas ubicaciones (Nueva York y Londres). En este caso, la aplicación podría beneficiarse de saber dónde se originó el pedido para poder convertir la hora relativa a la de una ubicación. Para lograrlo, una aplicación podría convertir toda la información común de marcas de tiempo (que utiliza GMT, en el ejemplo) en otra zona horaria específica y luego procesar la información. Consideremos una versión ampliada del ejemplo anterior, en la que el resultado es el siguiente:

ORDERNUMBER |      TIMESTAMP      | ORDERDETAILS
-------------+---------------------+--------------
           8 | 2012-04-13 13:40:41 | t3
           7 | 2012-04-13 13:40:25 | t2
           6 | 2012-04-13 13:40:13 | t1
           5 | 2012-04-13 13:34:32 | jki
           4 | 2012-04-13 13:33:49 | def
           3 | 2012-04-13 13:33:33 | abc
           2 | 2012-04-12 14:41:40 | Product A
           1 | 2012-04-12 14:33:03 | Product A

Estas entradas son todas marcas de tiempo GMT. Pueden convertirse en otros tiempos relativos utilizando funciones SQL, como se indica a continuación. En primer lugar, convertir a horario de verano del Pacífico:

SELECT ordernumber, timezone('PDT',
timestamp(substring(ordertimestamp,1,10),
timetz(substring(ordertimestamp, 12)))) as ts, orderdetails FROM
ordertable2 ORDER BY ts desc;

La salida es la siguiente:

ORDERNUMBER |           TS           | ORDERDETAILS
------------+------------------------+--------------
          8 | 2012-04-13 06:40:41-07 | t3
          7 | 2012-04-13 06:40:25-07 | t2
          6 | 2012-04-13 06:40:13-07 | t1
          5 | 2012-04-13 06:34:32-07 | jki
          4 | 2012-04-13 06:33:49-07 | def
          3 | 2012-04-13 06:33:33-07 | abc
          2 | 2012-04-12 07:41:40-07 | Product A
          1 | 2012-04-12 07:33:03-07 | Product A

En este ejemplo, la información de las mismas filas se convierte a la hora de verano del Este:

SELECT ordernumber, timezone('EDT',
timestamp(substring(ordertimestamp,1,10),
timetz(substring(ordertimestamp, 12)))) as ts, orderdetails FROM
ordertable2 ORDER BY ts desc;

La salida es la siguiente:

ORDERNUMBER |           TS           | ORDERDETAILS
------------+------------------------+--------------
          8 | 2012-04-13 09:40:41-04 | t3
          7 | 2012-04-13 09:40:25-04 | t2
          6 | 2012-04-13 09:40:13-04 | t1
          5 | 2012-04-13 09:34:32-04 | jki
          4 | 2012-04-13 09:33:49-04 | def
          3 | 2012-04-13 09:33:33-04 | abc
          2 | 2012-04-12 10:41:40-04 | Product A
          1 | 2012-04-12 10:33:03-04 | Product A

Este ejemplo, similar al ejemplo original, utiliza el tipo VARCHAR para capturar la información de la marca de tiempo:

INSERT INTO ordertable2 values (1, timezone('EDT', current_timestamp),
'Product A');

La fila de pedidos resultante en la tabla es la siguiente:

ORDERNUMBER |     ORDERTIMESTAMP     | ORDERDETAILS
------------+------------------------+--------------
          1 | 2012-01-19 09:12:06-05 | Product A

Es necesario disponer de información específica sobre la ubicación o la zona horaria en la captura de la sesión f. Para ello, puede introducir en la sesión un código de ubicación, una zona horaria, un desplazamiento de zona horaria o cualquier otro identificador. A continuación figura un cuadro de muestra:

ORDERNUMBER |    ORDERTIMESTAMP    | ORDERDETAILS | LOC_CODE
------------+----------------------+--------------+----------
          1 | 2012-01-19 09:12:06  | Product A    | 1

El campo LOC_CODE puede ser entonces una correspondencia con otra tabla que contenga detalles de localización:

LOC_CODE |   LOCATIONCITY   | LOCATIONTZ | TIMEZONEOFFSET
---------+------------------+------------+----------------
       1 | New York, NY     | EST        | -5