| Документация по PostgreSQL 9.1.1 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 8. Типы данных | Fast Forward | Next |
PostgreSQL поддерживает полный список SQL типов даты и времени, который представлен в Table 8-9. Операции, которые доступны для этих типов данных, описываются в Section 9.9.
Table 8-9. Типы даты/времени
| Имя | Размер хранения | Описание | Наименьшее значение | Наибольшее значение | Разрешение(шаг) |
|---|---|---|---|---|---|
| timestamp [ (p) ] [ without time zone ] | 8 байт | и дата и время (без часового пояса) | 4713 BC | 294276 AD | 1 микросекунда / 14 разрядов |
| timestamp [ (p) ] with time zone | 8 байт | и дата и время с часовым поясом | 4713 BC | 294276 AD | 1 микросекунда / 14 разрядов |
| date | 4 байта | дата (без часового пояса) | 4713 BC | 5874897 AD | 1 день |
| time [ (p) ] [ without time zone ] | 8 байт | только время (без даты) | 00:00:00 | 24:00:00 | 1 микросекунда / 14 разрядов |
| time [ (p) ] with time zone | 12 байт | время с часовым поясом | 00:00:00+1459 | 24:00:00-1459 | 1 микросекунда / 14 разрядов |
| interval [ fields ] [ (p) ] | 12 байт | интервал времени | -178000000 лет | 178000000 лет | 1 микросекунда / 14 разрядов |
Note: Стандарт SQL требует, чтобы написание просто timestamp было эквивалентно timestamp without time zone и PostgreSQL следует стандарту. (Версии до 7.3 считали, что timestamp with time zone.) timestamptz допускается как сокращение для timestamp with time zone; это расширенное поведение PostgreSQL.
Для типов time, timestamp и interval можно указывать необязательное значение точности p, которое задаёт количество дробных разрядов после запятой. По умолчанию, точность в явном виде не указывается. Допустимый диапазон значения p от 0 до 6 для типа timestamp и для типа interval.
Note: Если значения timestamp хранятся как восьмибайтное целое число (по умолчанию это так), то в пределах всего диапазона значений достигается точность в одну микросекунду. Если значения timestamp хранятся как число с плавающей запятой двойной точности (в случае выбора устаревшей опции при компиляции), то эффективное ограничение на точность может быть меньше 6. Значения timestamp хранятся как количество секунд перед или после 2000-01-01. Когда значения timestamp реализуются с использованием чисел с плавающей точкой, микросекундная точность достигается для дат, которые находятся внутри отрезка, начинающегося с 2000-01-01, но эта точность снижается для дат вне этого отрезка. Обратите внимание, что значения timestamp, использующие плавающую точку позволяют работать с большим диапазоном значений, чем указано выше: от 4713 BC до 5874897 AD.
Та же опция при компиляции также определяет будут ли значения time interval храниться как числа с плавающей точкой или как восьмибайтные целые числа. В случае чисел с плавающей точкой, бОльшие значения interval имеют меньшую точность из-за увеличения размера самого интервала.
Для типов time разрешается диапазон p от 0 до 6, когда для хранения значений используется восьмибайтное целое, или от 0 до 10, когда используется число с плавающей запятой.
Тип interval имеет дополнительную опцию, которая должна ограничивать набор сохраняемых полей с помощью одной из следующих фраз:
YEAR MONTH DAY HOUR MINUTE SECOND YEAR TO MONTH DAY TO HOUR DAY TO MINUTE DAY TO SECOND HOUR TO MINUTE HOUR TO SECOND MINUTE TO SECOND
Обратите внимание, что если указаны и поля и p, то поля должны включать SECOND, так как точность применима только к секундам.
Тип time with time zone определяется стандартом SQL, но это определение говорит о свойствах, которые приводят нас к сомнениям относительно пригодности. В большинстве случаев, комбинация типов date, time, timestamp without time zone и timestamp with time zone предоставляет полный диапазон функциональности для работы с датой и временем, который бы мог потребоваться какому-либо приложению.
Типы abstime и reltime имеют низкую точность и используются для внутренних целей. Вы должны воздержаться от использования этих типов в приложениях; эти внутренние типы в будущем могут исчезнуть.
Вводимые значения даты и времени примаются в любом разумном формате, включая ISO 8601, SQL-совместимый, традиционный формат POSTGRES и другие. Для некоторых форматов, порядок следования полей дня, месяца и года в значении даты является неоднозначным и для таких форматов поддерживается указание порядка следования этих полей. Установите параметр DateStyle в значение MDY, чтобы выбрать порядок следования месяц-день-год, в значение DMY, чтобы выбрать порядок следования день-месяц-год или в YMD, чтобы выбрать порядок следования год-месяц-день.
В PostgreSQL управление вводом значений даты и времени устроено более удобно, чем этого требует стандарт SQL. Смотрите Appendix B, чтобы узнать о точных правилах разбора вводимых значений даты/времени и о распознавании текстовых полей, включая месяцы, дни недели и часовые пояса.
Помните, что любые вводимые значения даты или времени необходимо заключать в одиночные кавычки, как и текстовые строки. Больше информации можно найти в Section 4.1.2.7. SQL требует следующего синтаксиса
тип [ (p) ] 'значение'
где p является необязательной спецификацией точности, которая задаётся целым числом, соответствующим количеству дробрых разрядов во втором поле. Точность может быть задана для типов time, timestamp и interval. Допустимые значения были рассмотрены выше. Если точность в спецификации константы не указана, то она устанавливается в значение по умолчанию для литеральных значений.
Table 8-10 показывает некоторые возможные формы ввода для типа date.
Table 8-10. Ввод значений даты
| Пример | Описание |
|---|---|
| 1999-01-08 | ISO 8601; 8 января в любом режиме (рекомендуемый формат) |
| January 8, 1999 | значение является однозначным для любого datestyle режима ввода |
| 1/8/1999 | 8 января в режиме MDY; 1 августа в режиме DMY |
| 1/18/1999 | 18 января в режиме MDY; в других режимах значение будет отвергнуто |
| 01/02/03 | 2 января, 2003 года в режиме MDY; 1 февраля, 2003 года в режиме DMY; 3 февраля, 2001 года в режиме YMD |
| 1999-Jan-08 | 8 января в любом режиме |
| Jan-08-1999 | 8 января в любом режиме |
| 08-Jan-1999 | 8 января в любом режиме |
| 99-Jan-08 | 8 января в режиме YMD, иначе ошибка |
| 08-Jan-99 | 8 января, за исключением режима YMD, в котором будет ошибка |
| Jan-08-99 | 8 января, за исключением режима YMD, в котором будет ошибка |
| 19990108 | ISO 8601; 8 января, 1999 года в любом режиме |
| 990108 | ISO 8601; 8 января, 1999 года в любом режиме |
| 1999.008 | год и номер дня в году |
| J2451187 | день по Юлианскому календарю |
| January 8, 99 BC | 99 год до Нашей Эры |
Типами времени являются time [ (p) ] without time zone и time [ (p) ] with time zone. Тип time эквивалентен типу time without time zone.
Правильные вводимые значения для этих типов состоят из времени дня, за которым следует необязательное значение часового пояса. (См. Table 8-11 и Table 8-12.) Если часовой пояс задаётся при вводе значений типа time without time zone, то она молча игнорируется. Вы также всегда можете задать дату, но она будет проигнорирована, за исключением случая, когда вы используете имя часового пояса, который реализует переход на летнее/зимнее время, как например America/New_York. В этом случае требуется указание даты, чтобы понять летнее или зимнее время нужно применять. Соответствующее смещение часового пояса записывается в значение time with time zone.
Table 8-11. Ввод значений времени
| Пример | Описание |
|---|---|
| 04:05:06.789 | ISO 8601 |
| 04:05:06 | ISO 8601 |
| 04:05 | ISO 8601 |
| 040506 | ISO 8601 |
| 04:05 AM | тоже, что и 04:05; AM не имеет значения |
| 04:05 PM | тоже, что и 16:05; значение часа должно быть <= 12 |
| 04:05:06.789-8 | ISO 8601 |
| 04:05:06-08:00 | ISO 8601 |
| 04:05-08:00 | ISO 8601 |
| 040506-08 | ISO 8601 |
| 04:05:06 PST | часовой пояс, заданный аббревиатурой |
| 2003-04-12 04:05:06 America/New_York | часовой пояс, заданный полным именем |
Table 8-12. Ввод значений часового пояса
| Пример | Описание |
|---|---|
| PST | Аббревиатура (от Pacific Standard Time) |
| America/New_York | Полное имя часового пояса |
| PST8PDT | спецификация часового пояса в стиле POSIX |
| -8:00 | ISO-8601 смещение для PST |
| -800 | ISO-8601 смещение для PST |
| -8 | ISO-8601 смещение для PST |
| zulu | Военная аббревиатура для UTC |
| z | Краткая форма zulu |
Информацию о том как задавать часовые пояса, см. в Appendix B.
Правильные вводимые значения для типа даты и времени состоят из слитного значения даты и времени, за которым следует необязательное значение часового пояса, за которым следует необязательный суффикс AD или BC. (В качестве альтернативы, AD/BC могут указываться перед часовым поясом, но так делать не рекомендуется.) Таким образом:
1999-01-08 04:05:06
и:
1999-01-08 04:05:06 -8:00
являются правильными значениями, которые соответствуют стандарту ISO 8601. В дополнение, поддерживается формат стандарта:
January 8 04:05:06 1999 PST
Стандарт SQL различает литералы типов timestamp without time zone и timestamp with time zone по наличию символа "+"; или "-" и смещения часового пояса, которое задаётся после времени. Следовательно, в соответствии со стандартом,
TIMESTAMP '2004-10-19 10:23:54'
имеет тип timestamp without time zone, в то время как значение
TIMESTAMP '2004-10-19 10:23:54+02'
имеет тип timestamp with time zone. PostgreSQL никогда не проверяет содержимое строки литерала перед тем как определить его тип и таким образом будет считать оба данных выше примера как timestamp without time zone. Чтобы убедиться, что литерал распознается как timestamp with time zone, придайте ему правильный для этого типа вид:
TIMESTAMP WITH TIME ZONE '2004-10-19 10:23:54+02'
В литерале, который распознан как timestamp without timezone, PostgreSQL будет молча игнорировать любые указания часового пояса. Таким образом, итоговое значение будет получено из полей даты/времени, которые присутствуют во вводимом значении и не будет скорректировано по часовому поясу.
Для типа timestamp with time zone, значение внутри, всегда хранится в UTC (Universal Coordinated Time, обычно известное как время Гринвичского (нулевого) меридиана или GMT). Вводимое значение, которое имеет явно заданный часовой пояс, конвертируется в UTC, используя смещение, соответствующее этому часовому поясу. Если при вводе часовой пояс не указан, то он берётся из системного параметра timezone и точно также конвертируется в UTC, используя смещение часового пояса, указанное в переменной timezone.
Когда выводится значение типа timestamp with time zone, оно всегда конвертируется из UTC в часовой пояс, заданный переменной timezone и отображается как местное время в этом поясе. Чтобы увидеть это же время в другом часовом поясе, или измените значение переменной timezone или используйте конструкцию AT TIME ZONE (см. Section 9.9.3).
Преобразования между типами timestamp without time zone и timestamp with time zone обычно означают, что значение timestamp without time zone должно быть принято или выдано как значение местного времени часового пояса, указанного в переменной timezone. Для преобразования с помощью AT TIME ZONE может быть задан другой часовой пояс.
PostgreSQL поддерживает для удобства несколько специальных значений ввода даты/времени, как показано в Table 8-13. Из этих значений infinity и -infinity специально представлены внутри СУБД и будут показываться в неизменном виде; но другие являются просто сокращениями, которые будут преобразованы при вводе в обычные значения даты/времени. (Например, now и подобные строки преобразоываются в определённое значение времени в момент, когда их читает СУБД.) Все такие значения, когда они используется в командах SQL, должны заключаться в одинарные кавычки.
Table 8-13. Специальные значения даты/времени
| Вводимая строка | Допустимые типы данных | Описание |
|---|---|---|
| epoch | date, timestamp | 1970-01-01 00:00:00+00 (Нулевое системное время Unix) |
| infinity | date, timestamp | позже, чем все другие временные штампы |
| -infinity | date, timestamp | раньше, чем все другие временные штампы |
| now | date, time, timestamp | время начала текущей транзакции |
| today | date, timestamp | полночь текущего дня |
| tomorrow | date, timestamp | полночь завтрашнего дня |
| yesterday | date, timestamp | полночь вчерашнего дня |
| allballs | time | 00:00:00.00 UTC |
Также получить текущее значение времени для соответствующих типов данных можно используя следующие, совместимые со стандартом SQL функции: CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP, LOCALTIME, LOCALTIMESTAMP. Последние четыре функции позволяют задать необязательную точность. (См. Section 9.9.4.) Обратите внимание, что есть функции SQL и что они не рапознаются при вводе.
Формат вывода значений типов даты/времени может быть установлен в одном из четырёх стилей: ISO 8601, SQL (Ingres), традиционный POSTGRES (Формат Unix date) или German. По умолчанию устанавливается формат ISO. (Стандарт SQL требует использования формата ISO 8601. Название формата вывода "SQL" является исторически сложившимся.) Table 8-14 показывает примеры каждого стиля вывода. Вывод значений типов date и time, разумеется, только часть даты и времени в соответствии с данными примерами.
Table 8-14. Стили вывода даты/времени
| Спецификация стиля | Описание | Пример |
|---|---|---|
| ISO | стандарт ISO 8601/SQL | 1997-12-17 07:37:16-08 |
| SQL | традиционный стиль | 12/17/1997 07:37:16.00 PST |
| POSTGRES | собственный стиль | Wed Dec 17 07:37:16 1997 PST |
| German | региональный стиль | 17.12.1997 07:37:16.00 PST |
В стилях SQL и POSTGRES, день идёт перед месяцем, если быд задан порядок полей DMY, в противном случае месяц следует перед днём. (См. Section 8.5.1 о том как эта настройка также отказывает эффект на интерпретацию вводимых значений.) В Table 8-15 показан пример.
Table 8-15. Соглашения по датам
| Установка стиля даты | Входимое значение | Пример вывода |
|---|---|---|
| SQL, DMY | день/месяц/год | 17/12/1997 15:37:16.00 CET |
| SQL, MDY | месяц/день/год | 12/17/1997 07:37:16.00 PST |
| Postgres, DMY | день/месяц/год | Wed 17 Dec 07:37:16 1997 PST |
Пользователь может выбрать нужные ему стили даты/времени с
помощью команды SET datestyle, параметра DateStyle в конфигурационном файле
postgresql.conf или с установив переменную
окружения PGDATESTYLE на сервере или клиенте.
Функция форматирования to_char
(см. Section 9.8) также может быть
использована как более гибкий способ форматирования выводимых
значений даты/времени.
Часовые пояса и соглашения по часовым поясам зависят не только геометрии планеты, но и от политического территориального деления. Часовые пояса во всём мире стали чем-то стандартным, начиная с 1900 года, но продолжают соответствующим образом изменяться, учитывая правила летнего/зимнего времени. В настоящий момент PostgreSQL использует широко-использумую базу данных zoneinfo часовых поясом для получения информации о исторических правилах часовых поясов. Для времени в будущем, берутся последние известные правила для данного часового пояса, которые продолжат изменяться в неопределённо далёком будущем.
PostgreSQL прикладывает усилия для совместимости со стандартом SQL при работе с типовыми операциями. Однако, в стандарте SQL есть разнородная смесь типов даты и времени, а также совместимых с ними типов. Вот две очевидные проблемы:
Хотя тип date не имеет ассоциированный с ним часовой пояс, тип time может её иметь. Часовые пояса в реальном мире имеют небольшую значимость, в отличие от ассоциированных с ними дат и времени, а смещение может изменяться в течении года при переходе на зимнее/летнее время.
Часовой пояс по умолчанию задаётся как постоянное цифровое смещение от времени UTC. Таким образом, становится невозможным адаптировать арифметические операции над датой/временем при переходе на летнее/зимнее время при работе с DST.
Из-за этих трудностей, мы рекомендуем при использовании часовых поясов использовать типы даты/времени, которые содержат как дату, так и время. Мы не рекомендуем использовать тип time with time zone (хотя он поддерживается PostgreSQL для старых приложений и для совместимости со стандартом SQL). PostgreSQL для всех типов, которые содержат только дату или только время использует ваш локальный часовой пояс.
Все даты, учитывающие часовой пояс и время хранятся внутри в UTC. Перед тем как значения будут выданы клиенту, они преобразуются в локальное время в соответствии с настройками, указанными в параметре timezone.
PostgreSQL позволяет указывать часовые пояса в трёх различных формах:
Полное имя часового пояса, например America/New_York. Распознаваемые имена часовых поясов перечислены в pg_timezone_names (см. Section 45.67). PostgreSQL использует для этой цели широко-используемые данные о часовых поясах zoneinfo, так что одни и те же имена также распоздаются и многими другими программами.
Аббревиатура имени часового пояса, например PST. Такие аббревиатуры часто задают конкретное смещение от UTC, в отличии от полных имён часовых поясов, которые могут неявно устанавливать также и правила перехода на летнее/зимнее время. Распознаваемые аббревиатуры перечислены в pg_timezone_abbrevs (см. (see Section 45.66). Вы не можете установить конфигурационные параметры timezone или log_timezone для аббревиатуры часового пояса, но вы можете использовать аббревиатуры при вводе значений даты/времени и с оператором AT TIME ZONE.
В дополнение к именам часовых поясов и их аббревиатурам, PostgreSQL будет работать и со спецификациями часовых поясов в стиле POSIX в форме STDсмещение или STDсмещениеDST, где STD — аббревиатура часового пояса, смещение — это числовое смещение в часах на запад от UTC, и DST — это необязательная аббревиатура летнего/зимнего времени, установленная на одночасовое опережение заданного смещения. Например, если значение EST5EDT не является уже распознаным именем часового пояса, оно будет принято и будет функционально эквивалентно времени Восточного Побережья США. Когда вводится имя часового пояса с переходом на летнее/зимнее время, работа с ним будет осуществляться в соответствии с такими же правилами перехода на летнее/зимнее время, которые используются в базе данных zoneinfo в записи posixrules. В стандартной установке PostgreSQL, posixrules — это тоже самое, что и US/Eastern, так что спецификации часовых поясов в стиле POSIX, следуют правилам перехода на летнее/зимнее время, применяемым в США. Если необходимо, вы можете настроить это, заменив файл posixrules.
Вкратце, отличие между аббревиатурами и полными именами: аббревиатуры всегда предоставляют постоянное смещение от UTC, в то время как полные имена подразумевают локальное правило перехода на летнее/зимнее время и таким образом имееют два возможных смещения от UTC.
Использовать часовые пояса в стиле POSIX, нужно осторожно, потому что данная возможность позволяет задать некорректные значения, которые будут приняты без сообщений об ошибках, поскольку проверка аббревиатур не производится. Например, SET TIMEZONE TO FOOBAR0 будет работать, но фактически система будет продолжать использовать данное значение как аббревиатуру для UTC. Кроме того, нужно помнить, что в именах часовых поясов POSIX, положительные смещения используются для поясов к западу от Гринвича. Во всём остальном PostgreSQL следует соглашению ISO-8601, что положительные смещения часовых поясов используются для поясов к востоку от Гринвича.
Во всех случаях, имена часовых поясов распознаются независимо от регистра букв. (Ранее в некоторых контекстах была зависимость от регистра, в других нет, но это изменилось, начиная с PostgreSQL версии 8.2.)
Ни полные имена ни аббревиатуры не являются жёстко встроенными в сервер; они берутся из конфигурационных файлов, хранящихся в подкаталогах .../share/timezone/ и .../share/timezonesets/ относительно каталога установки. (см. Section B.3).
Параметр timezone может быть установлен в файле postgresql.conf или любым другим стандартным способом, описанным в Chapter 18. Также существует несколько специальных способов его установки:
Если параметр timezone не задан в файле postgresql.conf или как опция командной строки для сервера, то сервер пытается использовать в качестве часового пояса по умолчанию значение переменной окружения TZ. Если переменная TZ не задана или не содержит в себе одно из известных PostgreSQL значений имени часового пояса, то сервер пытается определить часовой пояс по умолчанию у операционной системы, проверяя поведение библиотечной функции C localtime(). Часовой пояс по умолчанию выбирается в этом случае, как наиболее подходящий из известных PostgreSQL часовых поясов. (Эти правила также используются для выбора значения по умолчанию log_timezone, если оно не указано.)
В SQL команда SET TIME ZONE устанавливает часовой пояс для текущей сессии. Эта команда является альтернативой команды SET TIMEZONE TO, которая имеет более соответствующий SQL синтаксис.
Если на стороне клиента установлена переменная окружения PGTZ, то при подключении к серверу, её значение будет использоваться для отправки на сервер команды SET TIME ZONE, если клиентское приложение использует библиотеку libpq.
Значения типа interval могу быть записаны, используя следующий подробный синтаксис:
[@] длительность элемент [длительность элемент...] [направление]
где длительность является числом (возможно со знаком); элемент может принимать значение microsecond(микросекунда), millisecond(миллисекунда), second(секунда), minute(минута), hour(час), day(день), week(неделя), month(месяц), year(год), decade(декада), century(век), millennium(тысячелетие) или аббревиатуры одного из этих значений; направление может принимать значения ago(назад) или не указываться. Знак (@) также является необязательным. В соответствии с указанным знаком, будет добавлено необходимое количество различных элементов. ago изменяет знак у всех полей. Данный синтаксис также используется при выводе значений типа interval. Если переменная IntervalStyle установлена в postgres_verbose.
Длительность в днях, часах, минутах и секундах может быть указана без явных указаний соответствующих элементов. Например, '1 12:59:10' читается также как и '1 day 12 hours 59 min 10 sec'. Комбинация лет и месяцев может быть также задана с использованием знака чёрточки; например, '200-10' читается также как и '200 years 10 months'. (Эти укороченные формы фактически являются единственными из тех, что разрешает стандарт SQL и используются для вывода, когда значение IntervalStyle установлено в sql_standard.)
Значения типа interval могут также записываться по стандарту ISO 8601, используя либо "формат с указателями", согласно разделу стандарта 4.4.3.2, либо "альтернативный формат" раздела 4.4.3.3. Формат с указателями выглядит так:
P длительность элемент [ длительность элемент ...] [ T [ длительность элемент ...]]
Строка должна начинаться с P и может включать T, которые указывают на элементы времени дня. Доступные аббревиатуры элементов можно найти в Table 8-16. Элементы могут быть опущены и могут быть указаны в любом порядке, но элементы меньшие, чем день должны указываться после T. В особенности это касается M, смысл которого зависит от того, будет ли он указан до или после T.
Table 8-16. Аббревиатуры элементов интервалов по стандарту ISO 8601
| Аббревиатура | Пояснение |
|---|---|
| Y | Годы |
| M | Месяцы (в части, касающейся даты) |
| W | Недели |
| D | Дни |
| H | Часы |
| M | Минуты (в части, касающейся времени) |
| S | Секунды |
В альтернативном формате:
P [ годы-месяцы-дни ] [ T часы:минуты:секунды ]
строка должна начинаться с P, а T отделяет в интервале дату от времени. Значения задаются цифрами сходным с ISO 8601 образом.
При записи констант-интервалов по спецификации полей, или при назначении строки для колонки интервала, которая была задана по спецификации полей, интерпретация длительностей без явного указания элемента зависит от самих полей. Например, INTERVAL '1' YEAR читается как 1 год, в то время как INTERVAL '1' означает 1 секунду. Кроме того, значения полей "справа" от наименее значимого поля, разрешённого спецификацией полей, молча отбрасываются. Например, в результате написания INTERVAL '1 day 2:03:04' HOUR TO MINUTE будет отброшено поле секунд, но не поле дня.
В соответствии со стандартом SQL, все поля в значении интервала должны иметь один и тот же знак, так что начальный знак минус применяется ко всем полям; например знак минус в значении '-1 2:03:04' применяется и к дням и к часам/минутам/секундам. PostgreSQL позволяет полям иметь разные знаки и традиционно считает каждое поле в текстовом представлении как независящее от знака, так что часть час/минута/секунда рассматривается в данном выше примере как положительная. Если значение переменной IntervalStyle установлено в sql_standard, то начальный знак применяется ко всем полям (а не только к тем, где нет дополнительного знака). В противном случае, используется традиционная для PostgreSQL интерпретация. Чтобы избежать путаницы, рекомендуется явно указывать знак для каждого поля, если какое-либо поле является отрицательным.
Внутри значения interval хранятся как месяцы, дни и
секунды. Так сделано, потому что количество дней в месяце
разное, а продолжительность дня может быть 23 или 25 часов,
если используется переход на летнее/зимнее время. Поля месяцы и
дни являются целыми, а поле секунд может хранится в виде дроби.
Поскольку интервалы обычно создаются из строковых констант или
как разность значений timestamp, данный метод хранения
хорошо работает в большинстве случаев. Для коррекции дней и
часов, которые перекрывают их нормальные диапазоны, доступны
функции justify_days и justify_hours.
В подробном формате ввода и в некоторых полях более компактных форматов ввода, значения могут быть указаны в виде дробей; например '1.5 week' или '01:02:03.45'. Такой ввод для хранения преобразуется в соответствующее количество месяцев, дней и секунд. Преобразование выполняется по следующим правилам: 1 месяц = 30 дней, 1 день = 24 часам. Например, '1.5 month' будет 1 месяц и 15 дней. Только секунды будут показываться при выводе в виде дроби.
Table 8-17 показывает некоторые примеры допустимого ввода значений interval.
Table 8-17. Вводимые значения интервала
| Пример | Описание |
|---|---|
| 1-2 | формат по стандарту SQL: 1 год 2 месяца |
| 3 4:05:06 | формат по стандарту SQL: 3 дня 4 часа 5 минут 6 секунд |
| 1 year 2 months 3 days 4 hours 5 minutes 6 seconds | Традиционный формат Postgres: 1 год 2 месяца 3 дня 4 часа 5 минут 6 секунд |
| P1Y2M3DT4H5M6S | ISO 8601 "формат с указателями": то же значение, что и выше |
| P0001-02-03T04:05:06 | ISO 8601 "альтернативный формат": то же значение, что и выше |
Формат вывода значений типа interval может быть одним из четырёх: sql_standard, postgres, postgres_verbose или iso_8601, в зависимости от использования команды SET intervalstyle. По умолчанию установлен формат postgres. Table 8-18 показывает примеры каждого стиля вывода.
Стиль sql_standard выводит строковые значения, соответствующие стандарту SQL, если значения интервала соответствуют ограничениям стандарта (либо только год-месяц, либо только день-время, без смешивания положительных и отрицательных компонентов). В противном случае, вывод выглядит как стандартный литерал год-месяц, зак оторым следует литерал день-время с явным указанием знаков, добавляемых для избегания путницы на смешанных по знакам интервалах.
Вывод стиля postgres совпадает с выводом, который был в PostgreSQL до версии 8.4, когда параметр DateStyle был установлен в ISO.
Вывод стиля postgres_verbose совпадает с выводом PostgreSQL до версии 8.4, когда параметр DateStyle был установлен в не-ISO.
Вывод стиля iso_8601 совпадает с "форматом с указателями", который описан в разделе 4.4.3.2 стандарта ISO 8601.
Table 8-18. Примеры вывода значений интервала в разных стилях
| Спецификация стиля | Интервал Год-Месяц | Интервал День-Время | Смешанный интервал |
|---|---|---|---|
| sql_standard | 1-2 | 3 4:05:06 | -1-2 +3 -4:05:06 |
| postgres | 1 year 2 mons | 3 days 04:05:06 | -1 year -2 mons +3 days -04:05:06 |
| postgres_verbose | @ 1 year 2 mons | @ 3 days 4 hours 5 mins 6 secs | @ 1 year 2 mons -3 days 4 hours 5 mins 6 secs ago |
| iso_8601 | P1Y2M | P3DT4H5M6S | P-1Y-2M3DT-4H-5M-6S |
PostgreSQL использует для всех вычислений даты/времени Юлианский календарь. У него есть прекрасное свойство вычислять любую дату, которая следует за годом 4713 до н.э., потому что используется длина года, равная 365.2425 дням.
Соглашения по датам, которые использовались до 19-го века интересны, но не позволяют целостно использовать их при кодировании обработки даты/времени.