El manual establece los valores como:
- Valor bajo:4713 aC
- Valor alto:294276 dC
con la salvedad, como señaló Chris, de que -infinity
también es compatible.
Ver la nota más adelante en la misma página del manual; lo anterior solo es cierto si está utilizando marcas de tiempo enteras , que son los predeterminados en todas las versiones vagamente recientes de PostgreSQL. En caso de duda:
SHOW integer_datetimes;
Te contaré. Si está utilizando fechas y horas de punto flotante en su lugar, obtiene un mayor rango y menos precisión (no lineal). Cualquier intento de calcular el mínimo programáticamente debe hacer frente a esa restricción.
PostgreSQL no solo le permite convertir cero a una marca de tiempo para obtener la marca de tiempo mínima posible, ni tampoco tendría mucho sentido si estuviera usando fechas y horas de coma flotante. Tu puedes use la función de conversión de fecha juliana, pero esto le da la época no el tiempo mínimo :
postgres=> select to_timestamp(0);
to_timestamp
------------------------
1970-01-01 08:00:00+08
(1 row)
porque acepta valores negativos. Uno pensaría que darle un máximo negativo funcionaría, pero los resultados son sorprendentes hasta el punto en que me pregunto si tenemos un error envolvente al acecho aquí:
postgres=> select to_timestamp(-922337203685477);
to_timestamp
---------------------------------
294247-01-10 12:00:54.775808+08
(1 row)
postgres=> select to_timestamp(-92233720368547);
to_timestamp
---------------------------------
294247-01-10 12:00:54.775808+08
(1 row)
postgres=> select to_timestamp(-9223372036854);
to_timestamp
------------------------------
294247-01-10 12:00:55.552+08
(1 row)
postgres=> select to_timestamp(-922337203685);
ERROR: timestamp out of range
postgres=> select to_timestamp(-92233720368);
to_timestamp
---------------------------------
0954-03-26 09:50:36+07:43:24 BC
(1 row)
postgres=> select to_timestamp(-9223372036);
to_timestamp
------------------------------
1677-09-21 07:56:08+07:43:24
(1 row)
(¿Quizás relacionado con el hecho de que to_timestamp toma un doble, a pesar de que las marcas de tiempo se almacenan como números enteros en estos días?).
Creo que posiblemente sea más inteligente dejar que el rango de la marca de tiempo sea cualquier marca de tiempo en la que no obtenga un error. Después de todo, el rango de marcas de tiempo válidas no es continuo:
postgres=> SELECT TIMESTAMP '2000-02-29';
timestamp
---------------------
2000-02-29 00:00:00
(1 row)
postgres=> SELECT TIMESTAMP '2001-02-29';
ERROR: date/time field value out of range: "2001-02-29"
LINE 1: SELECT TIMESTAMP '2001-02-29';
por lo tanto, no puede asumir que solo porque un valor se encuentra entre dos marcas de tiempo válidas, es válido por sí mismo.