La entrada de fecha y hora se acepta en casi cualquier formato razonable, incluyendo ISO 8601, compatible con SQL, tradicional de POSTGRES y otros. Para algunos formatos, el orden del día, mes y año en la entrada de fecha es ambiguo y existe soporte para especificar el orden esperado de estos campos. Configura el parámetro DateStyle como MDY para seleccionar la interpretación mes-día-año, DMY para seleccionar la interpretación día-mes-año o YMD para seleccionar la interpretación año-mes-día.

PostgreSQL es más flexible en el manejo de la entrada de fecha y hora de lo que requiere el estándar SQL. Consulta la Appendix B para ver las reglas de análisis exactas de la entrada de fecha y hora y para los campos de texto reconocidos, incluyendo meses, días de la semana y zonas horarias.

Recuerda que cualquier entrada de literal de fecha u hora debe estar encerrada entre comillas simples, como las cadenas de texto. Consulta la Section 4.1.2.7 para obtener más información. SQL requiere la siguiente sintaxis:

tipo [ (p) ] 'valor'

donde p es una especificación de precisión opcional que indica el número de dígitos fraccionarios en el campo de segundos. La precisión se puede especificar para los tipos time, timestamp e interval, y puede variar de 0 a 6. Si no se especifica precisión en una constante, por defecto se toma la precisión del valor literal (pero no más de 6 dígitos).

1999-01-08 04:05:06

1999-01-08 04:05:06 -8:00

January 8 04:05:06 1999 PST

TIMESTAMP '2004-10-19 10:23:54'

TIMESTAMP '2004-10-19 10:23:54+02'

TIMESTAMP WITH TIME ZONE '2004-10-19 10:23:54+02'

El formato de salida de los tipos de fecha/hora se puede configurar en uno de los cuatro estilos: ISO 8601, SQL (Ingres), tradicional de POSTGRES (formato del comando date de Unix) o alemán. El valor predeterminado es el formato ISO. (El estándar SQL requiere el uso del formato ISO 8601. El nombre del formato de salida “SQL” es un accidente histórico). La Table 8.14 muestra ejemplos de cada estilo de salida. La salida de los tipos date y time suele ser solo la parte de la fecha o de la hora de acuerdo con los ejemplos mostrados. Sin embargo, el estilo de POSTGRES produce valores de solo fecha en formato ISO.

En los estilos SQL y POSTGRES, el día aparece antes que el mes si se ha especificado el orden de campos DMY; en caso contrario, el mes aparece antes que el día. (Consulta la Section 8.5.1 para ver cómo esta configuración también afecta la interpretación de los valores de entrada). La Table 8.15 muestra ejemplos.

En el estilo ISO, la zona horaria siempre se muestra como un desplazamiento numérico con signo desde UTC, utilizando el signo positivo para zonas al este de Greenwich. El desplazamiento se mostrará como hh (solo horas) si es un número entero de horas, de lo contrario como hh:mm si es un número entero de minutos, y como hh:mm:ss en caso contrario. (El tercer caso no es posible con ningún estándar moderno de huso horario, pero puede aparecer al trabajar con marcas de tiempo que son anteriores a la adopción de las zonas horarias estandarizadas). En los otros estilos de fecha, la zona horaria se muestra como una abreviatura alfabética si hay una de uso común en la zona actual. De lo contrario, aparece como un desplazamiento numérico con signo en el formato básico de ISO 8601 (hh o hhmm). Las abreviaturas alfabéticas que se muestran en estos estilos se toman de la entrada de la base de datos de zonas horarias de la IANA seleccionada actualmente por el parámetro de tiempo de ejecución TimeZone; no se ven afectadas por la configuración de timezone_abbreviations.

El estilo de fecha/hora puede ser seleccionado por el usuario mediante el comando SET datestyle, el parámetro DateStyle en el archivo de configuración postgresql.conf o la variable de entorno PGDATESTYLE en el servidor o cliente.

La función de formateo to_char (consulta la Section 9.8) también está disponible como una forma más flexible de dar formato a la salida de fecha y hora.

Las zonas horarias y las convenciones de zona horaria están influenciadas por decisiones políticas, no solo por la geometría de la Tierra. Las zonas horarias de todo el mundo se estandarizaron un poco durante la década de 1900, pero siguen siendo propensas a cambios arbitrarios, particularmente con respecto a las reglas de horario de verano. PostgreSQL utiliza la base de datos de zonas horarias de la IANA (Olson), de uso generalizado, para obtener información sobre las reglas históricas de zonas horarias. Para fechas en el futuro, se asume que las últimas reglas conocidas para una zona horaria determinada se seguirán observando indefinidamente en el futuro.

PostgreSQL se esfuerza por ser compatible con las definiciones del estándar SQL para el uso típico. Sin embargo, el estándar SQL tiene una mezcla extraña de tipos y capacidades de fecha y hora. Dos problemas obvios son:

Para abordar estas dificultades, recomendamos utilizar tipos de fecha y hora que contengan tanto fecha como hora cuando utilices zonas horarias. No recomendamos utilizar el tipo time with time zone (aunque es compatible con PostgreSQL para aplicaciones heredadas y para el cumplimiento del estándar SQL). PostgreSQL asume tu zona horaria local para cualquier tipo que contenga solo fecha u hora.

Todas las fechas y horas con zona horaria se almacenan internamente en UTC. Se convierten a la hora local en la zona especificada por el parámetro de configuración TimeZone antes de mostrarse al cliente.

PostgreSQL te permite especificar zonas horarias en tres formas diferentes:

En resumen, esta es la diferencia entre abreviaturas y nombres completos: las abreviaturas representan un desplazamiento específico de UTC, mientras que muchos de los nombres completos implican una regla de horario de verano local, por lo que tienen dos desplazamientos UTC posibles. Como ejemplo, 2014-06-04 12:00 America/New_York representa el mediodía hora local en Nueva York, que para esta fecha en particular era el horario de verano del Este (UTC-4). Así que 2014-06-04 12:00 EDT especifica ese mismo instante de tiempo. Pero 2014-06-04 12:00 EST especifica el mediodía de la hora estándar del Este (UTC-5), independientemente de si el horario de verano estaba nominalmente en efecto en esa fecha.

Para complicar las cosas, algunas jurisdicciones han utilizado la misma abreviatura de zona horaria para significar diferentes desplazamientos UTC en diferentes momentos; por ejemplo, en Moscú MSK ha significado UTC+3 en algunos años y UTC+4 en otros. PostgreSQL interpreta tales abreviaturas de acuerdo con lo que significaban (o habían significado más recientemente) en la fecha especificada; pero, al igual que con el ejemplo de EST anterior, esto no es necesariamente lo mismo que la hora civil local en esa fecha.

En todos los casos, los nombres y abreviaturas de zonas horarias se reconocen sin distinguir entre mayúsculas y minúsculas. (Este es un cambio con respecto a las versiones de PostgreSQL anteriores a la 8.2, que distinguían entre mayúsculas y minúsculas en algunos contextos pero no en otros).

Ni los nombres de zonas horarias ni las abreviaturas están integrados en el servidor; se obtienen de archivos de configuración almacenados bajo .../share/timezone/ and .../share/timezonesets/ del directorio de instalación (consulta la Section B.4).

El parámetro de configuración TimeZone se puede configurar en el archivo postgresql.conf, o en cualquiera de las otras formas estándar descritas en la Chapter 19. También hay algunas formas especiales de configurarlo:

Los valores de tipo interval se pueden escribir utilizando la siguiente sintaxis detallada:

[@] cantidad unidad [cantidad unidad...] [dirección]

donde cantidad es un número (posiblemente con signo); unidad es microsecond, millisecond, second, minute, hour, day, week, month, year, decade, century, millennium, o abreviaturas o plurales de estas unidades; dirección puede ser ago o vacío. El signo arroba (@) es ruido opcional. Las cantidades de las diferentes unidades se suman implícitamente teniendo en cuenta sus signos. ago niega todos los campos. Esta sintaxis también se utiliza para la salida de intervalos, si IntervalStyle está configurado como postgres_verbose.

Las cantidades de días, horas, minutos y segundos se pueden especificar sin marcas de unidad explícitas. Por ejemplo, '1 12:59:10' se lee igual que '1 day 12 hours 59 min 10 sec'. Además, se puede especificar una combinación de años y meses con un guion; por ejemplo, '200-10' se lee igual que '200 years 10 months'. (De hecho, estas formas más cortas son las únicas permitidas por el estándar SQL, y se utilizan para la salida cuando IntervalStyle está configurado como sql_standard).

Los valores de intervalo también se pueden escribir como intervalos de tiempo ISO 8601, utilizando bien el “formato con designadores” de la sección 4.4.3.2 del estándar o bien el “formato alternativo” de la sección 4.4.3.3. El formato con designadores tiene este aspecto:

P cantidad unidad [ cantidad unidad ...] [ T [ cantidad unidad ...]]

La cadena debe comenzar con una P, y puede incluir una T que introduce las unidades de hora del día. Las abreviaturas de unidades disponibles se dan en la Table 8.16. Las unidades se pueden omitir, y se pueden especificar en cualquier orden, pero las unidades menores que un día deben aparecer después de T. En particular, el significado de M depende de si está antes o después de T.

En el formato alternativo:

P [ años-meses-días ] [ T horas:minutos:segundos ]

la cadena debe comenzar con P, y una T separa las partes de fecha y hora del intervalo. Los valores se dan como números similares a las fechas ISO 8601.

Al escribir una constante de intervalo con una especificación de fields, o al asignar una cadena a una columna de intervalo que fue definida con una especificación de fields, la interpretación de las cantidades sin marcar depende de los fields. Por ejemplo, INTERVAL '1' YEAR se lee como 1 año, mientras que INTERVAL '1' significa 1 segundo. Además, los valores de campo “a la derecha” del campo menos significativo permitido por la especificación de fields se descartan silenciosamente. Por ejemplo, escribir INTERVAL '1 day 2:03:04' HOUR TO MINUTE da como resultado la eliminación del campo de segundos, pero no del campo de días.

De acuerdo con el estándar SQL, todos los campos de un valor de intervalo deben tener el mismo signo, por lo que un signo negativo inicial se aplica a todos los campos; por ejemplo, el signo negativo en el literal de intervalo '-1 2:03:04' se aplica tanto a los días como a las partes de horas/minutos/segundos. PostgreSQL permite que los campos tengan diferentes signos, y tradicionalmente trata cada campo en la representación textual como firmado independientemente, de modo que la parte de horas/minutos/segundos se considera positiva en este ejemplo. Si IntervalStyle está configurado como sql_standard, se considera que un signo inicial se aplica a todos los campos (pero solo si no aparecen signos adicionales). De lo contrario, se utiliza la interpretación tradicional de PostgreSQL. Para evitar ambigüedades, se recomienda adjuntar un signo explícito a cada campo si algún campo es negativo.

Internamente, los valores de tipo interval se almacenan como tres campos enteros: meses, días y microsegundos. Estos campos se mantienen separados porque el número de días en un mes varía, mientras que un día puede tener 23 o 25 horas si hay una transición de horario de verano de por medio. Una cadena de entrada de intervalo que utiliza otras unidades se normaliza en este formato y luego se reconstruye de manera estandarizada para la salida, por ejemplo:

SELECT '2 years 15 months 100 weeks 99 hours 123456789 milliseconds'::interval;
               interval
---------------------------------------
  3 years 3 mons 700 days 133:17:36.789

Aquí las semanas, que se entienden como “7 días”, se han mantenido separadas, mientras que las unidades de tiempo más pequeñas y más grandes se combinaron y normalizaron.

Los valores de los campos de entrada pueden tener partes fraccionarias, por ejemplo '1.5 weeks' o '01:02:03.45'. Sin embargo, debido a que interval almacena internamente solo campos enteros, los valores fraccionarios deben convertirse a unidades más pequeñas. Las partes fraccionarias de unidades mayores que meses se redondean para ser un número entero de meses, por ejemplo, '1.5 years' se convierte en '1 year 6 mons'. Las partes fraccionarias de semanas y días se calculan para ser un número entero de días y microsegundos, asumiendo 30 days por mes y 24 horas por día, por ejemplo, '1.75 months' se convierte en 1 mon 22 days 12:00:00. Solo los segundos se mostrarán como fraccionarios en la salida.

La Table 8.17 muestra algunos ejemplos de entrada de interval válida.

Como se explicó anteriormente, PostgreSQL almacena los valores de tipo interval como meses, días y microsegundos. Para la salida, el campo de meses se convierte a años y meses dividiendo por 12. El campo de días se muestra tal cual. El campo de microsegundos se convierte a horas, minutos, segundos y fracción de segundos. Por lo tanto, los meses, minutos y segundos nunca se mostrarán excediendo los rangos 0–11, 0–59 y 0–59 respectivamente, mientras que los campos mostrados de años, días y horas pueden ser bastante grandes. (Las funciones justify_days y justify_hours se pueden usar si es conveniente trasladar valores grandes de días u horas al siguiente campo superior).

El formato de salida del tipo de intervalo se puede configurar en uno de los cuatro estilos: sql_standard, postgres, postgres_verbose o iso_8601, usando el comando SET intervalstyle. El valor predeterminado es el formato postgres. La Table 8.18 muestra ejemplos de cada estilo de salida.

El estilo sql_standard produce una salida que se ajusta a la especificación del estándar SQL para cadenas de literales de intervalo, si el valor del intervalo cumple con las restricciones del estándar (bien solo año-mes o bien solo día-tiempo, sin mezclar componentes positivos y negativos). De lo contrario, la salida parece una cadena literal estándar de año-mes seguida de una cadena literal de día-tiempo, con signos explícitos agregados para eliminar la ambigüedad en intervalos con signos mixtos.

La salida del estilo postgres coincide con la salida de las versiones de PostgreSQL anteriores a la 8.4 cuando el parámetro DateStyle estaba configurado en ISO.

La salida del estilo postgres_verbose coincide con la salida de las versiones de PostgreSQL anteriores a la 8.4 cuando el parámetro DateStyle estaba configurado en una salida distinta de ISO.

La salida del estilo iso_8601 coincide con el “formato con designadores” descrito en la sección 4.4.3.2 del estándar ISO 8601.