with - timestamp postgresql example
Cómo saber una zona horaria de una marca de tiempo en postgresql 8.3 (4)
Supongo que tiene una columna llamada ct
que tiene el tipo TIMESTAMPTZ
en la tabla t
. Entonces puedes usar:
SELECT EXTRACT(TIMEZONE FROM ct) FROM t;
para obtener el desplazamiento de la zona horaria en segundos. 3600
te da 3600
de UTC
/ GMT
que significa GMT+1
, CET
o lo que sea. El valor devuelto depende de su configuración TIMEZONE
.
Ejemplo (vivo en Alemania, la zona horaria actual es GMT+1
/ CET
):
test=# select ''2008-01-01 12:00:00 GMT+5''::timestamptz;
timestamptz
------------------------
2008-01-01 18:00:00+01
test=# set timezone to ''gmt'';
SET
test=# select ''2008-01-01 12:00:00 GMT+5''::timestamptz;
timestamptz
------------------------
2008-01-01 17:00:00+00
Como puede ver, siempre muestra cualquier cosa en la zona horaria configurada. Por lo tanto, la compensación que obtendrá con EXTRACT(TIMEZONE FROM ...)
depende de su configuración TIMEZONE
. La zona horaria que se proporcionó en INSERT
se pierde porque no vale la pena guardarla. Lo que cuenta es que todo es correcto y eso no debería depender de la configuración TIMEZONE
. PostgreSQL lo hace muy bien.
Estoy usando postgresql 8.3 y me gustaría saber la zona horaria de una marca de tiempo en particular (una columna en una tabla).
En la documentación, he encontrado la palabra clave "zona horaria"
Pero no entiendo cómo aplicarlo en una columna de la tabla. Es posible ?
"PostgreSQL lo hace muy bien".
Realmente me gusta PostgreSQL, pero en esta característica particular no funciona bien. La zona horaria no está solo compensada con GMT. La zona horaria es estricta a las reglas políticas que implican el horario de verano. Como hay muchas zonas horarias con la misma compensación y diferentes reglas de horario de verano, cuando PG se olvida de la zona horaria original, pierde la información de hecho.
Personalmente almaceno la zona horaria original por separado para las fechas en que importa en el formato ''America / New_York''. Si alguien tiene una mejor solución, es bienvenido.
Dado que la marca de hora se vuelve a registrar por un instante en el tiempo en ZULU / GMT, que nunca cambia su compensación (ya que es la referencia), no es necesario registrar la zona horaria. Solo necesita sumar / restar el desplazamiento al desplazamiento de zona horaria GEOPOLITICA en PASADO, PRESENTE o FUTURO.
Usted DEBE saber el TIMERO GEOPOLÍTICO exacto en vigencia en el lugar al que se aplica el tiempo en el momento en que se aplica para los propósitos PASADOS y PRESENTES.
Para instancias futuras en el tiempo, esto se vuelve más problemático, tal vez. Aún así debería funcionar. Piensa en la puesta de sol. Si alguna ubicación de la Tierra tiene un atardecer a la medianoche hora ZULU (en algún lugar sobre el Océano Atlántico o el norte de Canadá a Alaska en invierno en el hemisferio norte), y ese tiempo se supone que es 8 PM (-4: 00 desplazamiento) en ese lugar en en el momento en que lo graba en el sistema y lo registra como ''fecha de invierno en el futuro a las 8:00 PM'', se grabará como 24:00 GMT en la base de datos.
Ahora, ese lugar en la tierra se pone al corriente con su * ss y se da por vencido con el conocimiento del tiempo geográfico relacionado, y llama a su zona horaria - ''+11: 55''. Entonces para ellos cuando es medianoche en Inglaterra (medianoche GMT) QUIEREN llamarlo 11:55 a.m., totalmente su elección. Cuando cualquier computadora desea mostrar esa fecha en el futuro para esa ubicación (es decir, esa zona horaria geopolítica), la llamarán 11:55 AM, incluso si el sol se está poniendo. Y, por supuesto, SERÁ el día ADELANTE del día que lo planeó :-) Su problema.
En Postgres, la zona horaria de entrada original se pierde incluso si almacena el valor de fecha y hora en la marca de tiempo con el tipo de datos de zona horaria .
Desventaja:
Di si tengo datos de fecha y hora (junto con la información de la zona horaria) de cuando las personas usan su aplicación de Facebook en todo el mundo. Ahora guardo esos valores en la marca de tiempo con el tipo de datos de zona horaria . Un día al azar Quiero ver qué tan fuertemente las personas usan su aplicación FB en la mañana en comparación con la noche y si la misma tendencia se ve en todos los países. Pero espera, ya no tengo la información de la zona horaria. Sentado en DC, lo que puedo ver es cómo se desarrolló la actividad en todo el mundo cuando eran las 10 a.m. EST.
Ventaja:
Si está comparando dos fuentes de datos con la marca de tiempo de la misma zona horaria, una fue almacenada como lo que se mostraba el reloj local y otra almacenada al convertirla en UTC. Aquí lo que puede hacer es almacenar la marca de tiempo en el tipo de datos timestamptz e indicar a qué zona horaria pertenece y luego puede compararlos fácilmente.
Por ejemplo,
Una actividad en la zona horaria PST se registró en 2014-10-19 10:23:54
. Ahora dos fuentes de datos separadas lo almacenan por separado. Datasource1 lo almacenó como 2004-10-19 10:23:54 PST
, Datasource2 lo almacenó como 2014-10-19 18:23:54 UTC
. Si están almacenados en el tipo de datos timestamptz , le mostrará el mismo momento cuando lo haga
SELECT datasource1.time, datasource2.time