Tipo de campo PostgreSQL para unix timestamp?

Tipo de campo PostgreSQL para unix marca de tiempo:

  • para almacenarlo como sello de tiempo unix
  • para recuperarlo como una marca de tiempo unix también.

Han estado pasando por Tipos de Fecha/Hora PostgreSQL V 9.1.

  • Es entero la mejor manera de ir!? (esto es lo que había hecho cuando estaba usando MySQL. Había utilizado int(10))
Author: ThinkingMonkey, 2012-08-03
Source

4 answers

Entero sería bueno, pero no lo suficientemente bueno, porque postgresql no soporta tipos sin signo

 3
Author: CyberDem0n,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-08-03 16:00:09

La marca de tiempo epoch de unix en este momento (2014-04-09) es 1397071518. Así que necesitamos un tipo de datos capaz de almacenar un número al menos este grande.

¿Qué tipos de datos están disponibles?

Si se refiere a la documentación de PostgreSQL sobre tipos numéricos encontrará las siguientes opciones: 

Name      Size     Minimum               Maximum
smallint  2 bytes  -32768                +32767
integer   4 bytes  -2147483648           +2147483647
bigint    8 bytes  -9223372036854775808  +9223372036854775807

¿Qué significa eso en términos de representación del tiempo?

Ahora, podemos tomar esos números y convertirlos en fechas usando una época convertidor:

Name      Size     Minimum Date      Maximum Date
smallint  2 bytes  1969-12-31        1970-01-01
integer   4 bytes  1901-12-13        2038-01-18
bigint    8 bytes  -292275055-05-16  292278994-08-17

Tenga en cuenta que en última instancia, el uso de segundos te pone tan lejos en el pasado y el futuro que probablemente no importa. El resultado que he dado es para si representas la época de unix en milisegundos.

Entonces, ¿qué hemos aprendido?

  1. smallint es claramente una mala elección.
  2. integer es una opción decente por el momento, pero su software explotará en el año 2038. El apocalipsis del Y2K no tiene nada sobre el Año 2038 Problema.
  3. Usar bigint es la mejor opción. Esto está preparado para el futuro contra la mayoría de las necesidades humanas concebibles, aunque el Doctor todavía puede criticarlo.

Puede o no considerar si no sería mejor almacenar su marca de tiempo en otro formato como el estándar ISO 8601.

 50
Author: Richard,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-04-09 19:40:17

Simplemente usaría TIMESTAMP CON(OUT) TIME ZONE y usaría EXTRACT para obtener una representación de marca de tiempo UNIX cuando la necesite.

Comparar 

SELECT NOW();

Con 

SELECT EXTRACT(EPOCH FROM NOW());
 21
Author: GordonM,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-08-03 15:57:00

No entiendo por qué la pregunta tiene algunos votos negativos.

De todos modos, he encontrado una pregunta estrechamente relacionada en el sitio Database Administrators (con muchos votos positivos).

Esto es solo para sugerir echar un vistazo allí, ya que hay una información mucho más completa sobre este tema no trivial.

 5
Author: jap1968,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-04-13 12:42:36