8.5. Типы даты/времени#

8.5. Типы даты/времени

8.5. Типы даты/времени

Tantor SE поддерживает полный набор типов данных для даты и времени SQL, показанных в Таблица 8.9. Операции, доступные для этих типов данных, описаны в Раздел 9.9. Даты подсчитываются в соответствии с григорианским календарем, даже в годах до введения этого календаря (см. Раздел B.6 для получения дополнительной информации).

Таблица 8.9. Типы даты/времени

ИмяРазмер хранилищаОписаниеНизкое значениеВысокое значениеРазрешение
timestamp [ (p) ] [ without time zone ]8 байти дата, и время (без часового пояса)4713 г. до н.э.294276 г. н.э.1 микросекунда
timestamp [ (p) ] with time zone8 байткак дата и время, с часовым поясом4713 г. до н. э.294276 г. н. э.1 микросекунда
date4 байтадата (без времени суток)4713 г. до н.э.5874897 г. н.э.1 день
time [ (p) ] [ without time zone ]8 байтвремя суток (без даты)00:00:0024:00:001 микросекунда
time [ (p) ] with time zone12 bytesвремя суток (без даты), с часовым поясом00:00:00+155924:00:00-15591 микросекунда
interval [ fields ] [ (p) ]16 байтинтервал времени-178000000 лет178000000 лет1 микросекунда

Примечание

Стандарт SQL требует, чтобы запись просто timestamp была эквивалентна timestamp without time zone, и Tantor SE соблюдает это поведение. timestamptz принимается как сокращение для timestamp with time zone; это расширение Tantor SE.

time, timestamp и interval принимают необязательное значение точности p, которое указывает количество десятичных знаков, сохраняемых в поле секунд. По умолчанию, точность не ограничена. Допустимый диапазон значений p от 0 до 6.

Тип 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

Обратите внимание, что если указаны и field, и p, то field должны включать SECOND, поскольку точность применяется только к секундам.

Тип time with time zone определен в SQL стандарте, но его определение обладает свойствами, которые вызывают сомнения в его полезности. В большинстве случаев комбинация типов date, time, timestamp without time zone и timestamp with time zone должна обеспечить полный набор функциональности для работы с датой и временем, необходимый для любого приложения.

8.5.1. Ввод даты/времени

Входные данные даты и времени принимаются в почти любом разумном формате, включая ISO 8601, совместимый с SQL, традиционный POSTGRES и другие. Для некоторых форматов порядок дня, месяца и года во входных данных даты является неоднозначным, и есть поддержка указания ожидаемого порядка этих полей. Установите параметр DateStyle в MDY для выбора интерпретации месяц-день-год, DMY - день-месяц-год или YMD - год-месяц-день.

Tantor SE более гибко обрабатывает ввод даты/времени, чем требует стандарт SQL. См. Предметный указатель B для точных правил разбора ввода даты/времени и для распознаваемых текстовых полей, включая месяцы, дни недели и часовые пояса.

Помните, что любой ввод литерала даты или времени должен быть заключен в апострофы, как текстовые строки. См. Раздел 4.1.2.7 для получения дополнительной информации. SQL требует следующий синтаксис

type [ (p) ] 'value'

где p - это необязательная спецификация точности, указывающая количество десятичных знаков в поле секунд. Точность может быть указана для типов time, timestamp и interval и может варьироваться от 0 до 6. Если точность не указана в спецификации константы, она по умолчанию равна точности литерального значения (но не более 6 знаков).

8.5.1.1. Даты

Таблица 8.10 показывает некоторые возможные входные данные для типа date.

Таблица 8.10. Ввод даты

ПримерОписание
1999-01-08ISO 8601; 8 января в любом режиме (рекомендуемый формат)
8 января 1999однозначно в любом режиме ввода datestyle
1/8/19998 января в режиме MDY; 1 августа в режиме DMY
1/18/199918 января в режиме MDY; отклонено в других режимах
01/02/032 января 2003 года в режиме MDY; 1 февраля 2003 года в режиме DMY; 3 февраля 2001 года в режиме YMD
1999-Янв-088 января в любом режиме
08-янв-19998 января в любом режиме
08-Янв-19998 января в любом режиме
99-Jan-088 января в режиме YMD, иначе ошибка
08-Янв-998 января, за исключением ошибки в режиме YMD
08-янв-998 января, за исключением ошибки в режиме YMD
19990108ISO 8601; January 8, 1999 in any mode
990108ISO 8601; January 8, 1999 in any mode
1999.008год и день года
J2451187Дата Юлиана
8 января 99 г. до н.э.год 99 до н.э.

8.5.1.2. Времена

Типы времени суток - это time [ (p) ] without time zone и time [ (p) ] with time zone. Просто time эквивалентно time without time zone.

Допустимый ввод для этих типов состоит из времени суток, за которым следует необязательная часовая зона. (См. Таблица 8.11 и Таблица 8.12.) Если часовая зона указана во вводе для time without time zone, она тихо игнорируется. Вы также можете указать дату, но она будет проигнорирована, за исключением случаев, когда вы используете название часовой зоны, которое включает правило летнего времени, такое как America/New_York. В этом случае указание даты необходимо для определения, применяется ли стандартное или летнее время. Соответствующий смещение часовой зоны записывается в значении time with time zone и выводится как сохранено; оно не корректируется в соответствии с активной часовой зоной.

Таблица 8.11. Ввод времени

ПримерОписание
04:05:06.789ISO 8601
04:05:06ISO 8601
04:05ISO 8601
040506ISO 8601
04:05 AMто же самое, что и 04:05; AM не влияет на значение
04:05 PMто же самое, что и 16:05; входное значение часа должно быть <= 12
04:05:06.789-8ISO 8601, с часовым поясом в виде смещения относительно UTC
04:05:06-08:00ISO 8601, с часовым поясом в виде смещения относительно UTC
04:05-08:00ISO 8601, с часовым поясом в виде смещения относительно UTC
040506-08ISO 8601, с часовым поясом в виде смещения относительно UTC
040506+0730ISO 8601, с десятичным часовым поясом в качестве смещения относительно UTC
040506+07:30:00UTC смещение указано в секундах (не допускается в ISO 8601)
04:05:06 PSTчасовой пояс, указанный с помощью сокращения
2003-04-12 04:05:06 America/New_Yorkчасовой пояс, указанный полным названием

Таблица 8.12. Ввод часового пояса

ПримерОписание
PSTСокращение (для Тихоокеанского стандартного времени)
America/New_YorkПолное название часового пояса
PST8PDTСпецификация временной зоны в стиле POSIX
-8:00:00UTC смещение для PST
-8:00Смещение UTC для PST (расширенный формат ISO 8601)
-800Смещение UTC для PST (базовый формат ISO 8601)
-8Смещение UTC для PST (базовый формат ISO 8601)
zuluВоенное сокращение для UTC
zКраткая форма для zulu (также в ISO 8601)

Ссылка на Раздел 8.5.3 содержит дополнительную информацию о том, как указывать часовые пояса.

8.5.1.3. Временные метки

Допустимый ввод для типов временных меток состоит из конкатенации даты и времени, за которыми может следовать необязательная временная зона, за которой может следовать необязательное значение 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. Tantor SE никогда не анализирует содержимое литеральной строки перед определением ее типа, и поэтому будет рассматривать оба примера как timestamp without time zone. Чтобы гарантировать, что литерал будет рассматриваться как timestamp with time zone, укажите ему правильный явный тип:

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

В литерале, который был определен как timestamp without time zone, Tantor SE будет молча игнорировать любую указанную временную зону. То есть, полученное значение происходит из полей даты/времени во входном значении и не корректируется для временной зоны.

Для timestamp with time zone внутреннее хранение значения всегда в формате UTC (Universal Coordinated Time, традиционно известное как Greenwich Mean Time, GMT). Значение ввода, в котором указан явный часовой пояс, преобразуется в UTC с использованием соответствующего смещения для этого часового пояса. Если во входной строке не указан часовой пояс, то предполагается, что он находится в часовом поясе, указанном в параметре TimeZone системы, и преобразуется в UTC с использованием смещения для зоны timezone.

Когда значение timestamp with time zone выводится, оно всегда преобразуется из UTC в текущую временную зону timezone и отображается как локальное время в этой зоне. Чтобы увидеть время в другой временной зоне, либо измените timezone, либо используйте конструкцию AT TIME ZONE (см. Раздел 9.9.4).

Преобразования между типами timestamp without time zone и timestamp with time zone обычно предполагают, что значение типа timestamp without time zone должно быть взято или предоставлено в локальном времени timezone. Для преобразования можно указать другой часовой пояс с помощью AT TIME ZONE.

8.5.1.4. Специальные значения

Tantor SE поддерживает несколько специальных значений для ввода даты/времени для удобства, как показано в Таблица 8.13. Значения infinity и -infinity особенно представлены внутри системы и будут отображаться без изменений; но остальные просто являются сокращениями, которые будут преобразованы в обычные значения даты/времени при чтении. (В частности, строки now и связанные с ними преобразуются в конкретное значение времени сразу после их чтения). Все эти значения должны быть заключены в апострофы при использовании в качестве констант в SQL-командах.

Таблица 8.13. Специальные входные данные для даты/времени

Входная строкаДопустимые типыОписание
epochdate, timestamp1970-01-01 00:00:00+00 (нулевое время Unix-системы)
infinitydate, timestampпозже всех остальных временных меток
-infinitydate, timestampраньше всех остальных временных меток
nowdate, time, timestampвремя начала текущей транзакции
todaydate, timestampполночь (00:00) сегодня
tomorrowdate, timestampполночь (00:00) завтра
yesterdaydate, timestampполночь (00:00) вчера
allballstime00:00:00.00 UTC

Следующие функции, совместимые с SQL, также могут использоваться для получения текущего значения времени для соответствующего типа данных: CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP, LOCALTIME, LOCALTIMESTAMP. (См. Раздел 9.9.5). Обратите внимание, что это SQL-функции и не распознаются в строках ввода данных.

Предостережение

В то время как входные строки now, today, tomorrow и yesterday можно использовать в интерактивных SQL-командах, они могут иметь неожиданное поведение, когда команда сохраняется для последующего выполнения, например, в подготовленных операторах, представлениях и определениях функций. Строка может быть преобразована в конкретное значение времени, которое продолжает использоваться даже после того, как оно устареет. В таких контекстах лучше использовать одну из SQL-функций. Например, CURRENT_DATE + 1 безопаснее, чем 'tomorrow'::date.

8.5.2. Вывод даты/времени

Формат вывода типов даты/времени может быть установлен в один из четырех стилей: ISO 8601, SQL (Ingres), традиционный формат POSTGRES (формат даты Unix-приложения date) или немецкий. По умолчанию используется формат ISO. (Стандарт SQL требует использования формата ISO 8601. Название формата вывода SQL является исторической случайностью). В таблице Таблица 8.14 приведены примеры каждого стиля вывода. Вывод типов date и time обычно содержит только дату или время в соответствии с приведенными примерами. Однако, стиль POSTGRES выводит только значения даты в формате ISO.

Таблица 8.14. Стили вывода даты/времени

Спецификация стиляОписаниеПример
ISOISO 8601, стандарт SQL1997-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

Примечание

ISO 8601 определяет использование заглавной буквы T для разделения даты и времени. Tantor SE принимает этот формат при вводе, но при выводе использует пробел вместо T, как показано выше. Это сделано для удобочитаемости и согласованности с RFC 3339 а также некоторыми другими системами управления базами данных.

В стилях SQL и POSTGRES день отображается перед месяцем, если указано упорядочивание полей DMY, в противном случае месяц отображается перед днем. (См. Раздел 8.5.1 для того, как это настройка также влияет на интерпретацию входных значений). Таблица 8.15 показывает примеры.

Таблица 8.15. Конвенции порядка дат

datestyle УстановкаУпорядочивание вводаПример вывода
SQL, DMYday/month/year17/12/1997 15:37:16.00 CET
SQL, MDYmonth/day/year12/17/1997 07:37:16.00 PST
Postgres, DMYday/month/yearWed 17 Dec 07:37:16 1997 PST

В стиле ISO часовой пояс всегда указывается как знаковое числовое смещение относительно UTC, с положительным знаком для зон, находящихся к востоку от Гринвича. Смещение будет показано как hh (только часы), если оно является целым числом часов, иначе как hh:mm (целое число минут), или как hh:mm:ss. (Третий случай невозможен с любым современным стандартом часовых поясов, но он может появиться при работе с метками времени, предшествующими принятию стандартизированных часовых поясов). В других стилях даты часовой пояс показывается как алфавитное сокращение, если оно широко используется в текущей зоне. В противном случае он отображается как числовое смещение в базовом формате ISO 8601 (hh или hhmm).

Стиль даты/времени может быть выбран пользователем с помощью команды SET datestyle, параметра DateStyle в файле конфигурации postgresql.conf или переменной окружения PGDATESTYLE на сервере или клиенте.

Функция форматирования to_char (см. Раздел 9.8) также доступна как более гибкий способ форматирования вывода даты/времени.

8.5.3. Часовые пояса

Часовые пояса и конвенции по часовым поясам подвержены влиянию политических решений, а не только геометрии Земли. Часовые пояса по всему миру стали отчасти стандартизированными в течение 1900-х годов, но продолжают быть подвержены произвольным изменениям, особенно в отношении правил перехода на летнее время. Tantor SE использует широко используемую базу данных часовых поясов IANA (Olson) для получения информации о исторических правилах часовых поясов. Для времени в будущем предполагается, что последние известные правила для данного часового пояса будут продолжать соблюдаться в бесконечно удаленном будущем.

Tantor SE стремится быть совместимым с определениями стандарта SQL для типичного использования. Однако стандарт SQL имеет странное сочетание типов и возможностей для работы с датой и временем. Два очевидных проблемы:

  • Хотя тип date не может иметь связанную временную зону, тип time может. В реальном мире временные зоны имеют мало смысла, если они не связаны с датой, а также с временем, так как смещение может меняться в течение года с учетом границ перехода на летнее время.

  • Временная зона по умолчанию указывается как постоянное числовое смещение относительно UTC. Поэтому невозможно адаптироваться к переходу на летнее время при выполнении арифметических операций с датой/временем через границы DST.

Для решения этих трудностей мы рекомендуем использовать типы даты/времени, которые содержат и дату, и время при использовании часовых поясов. Мы не рекомендуем использовать тип time with time zone (хотя он поддерживается Tantor SE для устаревших приложений и соблюдения стандарта SQL). Tantor SE предполагает использование вашего локального часового пояса для любого типа, содержащего только дату или время.

Все даты и время, связанные с часовыми поясами, хранятся внутри в формате UTC. Они преобразуются в местное время в зоне, указанной в параметре конфигурации TimeZone, перед отображением клиенту.

Tantor SE позволяет указывать часовые пояса в трех различных формах:

  • Полное название часового пояса, например America/New_York. Распознаваемые названия часовых поясов перечислены в представлении pg_timezone_names (см. Раздел 52.32). Tantor SE использует широко используемые данные о часовых поясах IANA для этой цели, поэтому те же самые названия часовых поясов также распознаются другим программным обеспечением.

  • Сокращение часового пояса, например PST. Такая спецификация просто определяет определенное смещение от UTC, в отличие от полных названий часовых поясов, которые могут подразумевать набор правил перехода на летнее время. Распознаваемые сокращения перечислены в представлении pg_timezone_abbrevs (см. Раздел 52.31). Вы не можете установить параметры конфигурации TimeZone или log_timezone на сокращение часового пояса, но вы можете использовать сокращения во входных значениях даты/времени и с оператором AT TIME ZONE.

  • В дополнение к именам и сокращениям часовых поясов, Tantor SE принимает спецификации часовых поясов в стиле POSIX, описанные в Раздел B.5. Обычно предпочтительнее использовать именованный часовой пояс, но это может быть необходимо, если нет подходящей записи часового пояса IANA.

Вкратце, разница между сокращениями и полными названиями заключается в следующем: сокращения представляют собой конкретное смещение относительно UTC, в то время как многие полные названия подразумевают правило локального перехода на летнее время и, следовательно, имеют два возможных смещения относительно UTC. Например, 2014-06-04 12:00 America/New_York представляет собой полдень местного времени в Нью-Йорке, которое для этой конкретной даты было восточным летним временем (UTC-4). Таким образом, 2014-06-04 12:00 EDT указывает на то же самое мгновение времени. Но 2014-06-04 12:00 EST указывает на полдень восточного стандартного времени (UTC-5), независимо от того, было ли летнее время официально введено в действие в эту дату.

Чтобы усложнить ситуацию, некоторые юрисдикции используют одно и то же сокращение часового пояса для обозначения разных смещений относительно UTC в разное время; например, в Москве MSK означает UTC+3 в некоторые годы и UTC+4 в другие. PostgreSQL интерпретирует такие сокращения в соответствии с тем, что они означали (или недавно означали) в указанную дату; но, как и в примере с EST выше, это не обязательно совпадает с местным гражданским временем в эту дату.

Во всех случаях имена часовых поясов и их сокращения распознаются без учета регистра. (Это отличается от предыдущих версий PostgreSQL до 8.2, которые были чувствительны к регистру в некоторых контекстах, но не в других.)

Временные зоны и их сокращения не зашиты в сервере; они получаются из файлов конфигурации, хранящихся в каталогах .../share/timezone/ и .../share/timezonesets/ установочного каталога (см. Раздел B.4).

Параметр конфигурации TimeZone может быть установлен в файле postgresql.conf или в любом из других стандартных способов, описанных в Глава 19. Также есть несколько специальных способов его установки:

  • SQL-команда SET TIME ZONE устанавливает часовой пояс для сессии. Это альтернативное написание команды SET TIMEZONE TO с более совместимым с синтаксисом SQL.

  • Переменная среды PGTZ используется клиентами libpq для отправки команды SET TIME ZONE на сервер при подключении.

8.5.4. Ввод интервала

Значения типа interval могут быть записаны с использованием следующего подробного синтаксиса:

[@] quantity unit [quantity unit...] [direction]

где quantity - это число (возможно, со знаком); unit - это microsecond, millisecond, second, minute, hour, day, week, month, year, decade, century, millennium, или сокращения или множественное число этих единиц; direction может быть ago или пустым. Знак собаки (@) является необязательным шумом. Количество разных единиц неявно складывается с соответствующим учетом знака. ago отрицает все поля. Этот синтаксис также используется для вывода интервала, если IntervalStyle установлен в postgres_verbose.

Количества дней, часов, минут и секунд можно указать без явных обозначений единиц. Например, '1 12:59:10' читается так же, как '1 день 12 часов 59 минут 10 секунд'. Также, комбинация лет и месяцев может быть указана с помощью дефиса; например '200-10' читается так же, как '200 лет 10 месяцев'. (Эти более короткие формы фактически являются единственно допустимыми согласно стандарту SQL и используются для вывода, когда значение IntervalStyle установлено в sql_standard).

Значения интервалов также могут быть записаны в виде интервалов времени ISO 8601, используя либо формат с обозначениями из раздела 4.4.3.2 стандарта, либо альтернативный формат из раздела 4.4.3.3. Формат с обозначениями выглядит следующим образом:

P quantity unit [ quantity unit ...] [T [ quantity unit ...]]

Строка должна начинаться с тега P и может включать тег T, который вводит единицы времени суток. Доступные сокращения единиц приведены в Таблица 8.16. Единицы можно опустить или указать в любом порядке, но единицы, меньшие чем день, должны появляться после тега T. В частности, значение M зависит от того, идет ли он перед или после тега T.

Таблица 8.16. ISO 8601 Единицы измерения интервалов

СокращениеЗначение
YГоды
ММесяцы (в части даты)
WНедели
DДни
HЧасы
ММинуты (во временной части)
SСекунды

В альтернативном формате:

P [ years-months-days ] [ T hours:minutes:seconds ]

строка должна начинаться с P, а T разделяет части даты и времени интервала. Значения задаются в виде чисел, аналогичных датам ISO 8601.

При записи константы интервала с указанием полей fields или при присвоении строки столбцу интервала, определенному с указанием полей fields, интерпретация неотмеченных величин зависит от полей fields. Например, INTERVAL '1' YEAR означает 1 год, тогда как INTERVAL '1' означает 1 секунду. Кроме того, значения полей справа от наименее значимого поля, разрешенного в полях fields, молча отбрасываются. Например, запись INTERVAL '1 day 2:03:04' HOUR TO MINUTE приводит к отбрасыванию поля секунд, но не поля дней.

Согласно стандарту SQL все поля значения интервала должны иметь одинаковый знак, поэтому ведущий отрицательный знак применяется ко всем полям; например, отрицательный знак в литерале интервала '-1 2:03:04' применяется как к дням, так и к часам/минутам/секундам. Tantor SEпозволяет полям иметь разные знаки и традиционно рассматривает каждое поле в текстовом представлении как независимо знаковое, так что в этом примере часть с часами/минутами/секундами считается положительной. Если значение IntervalStyle установлено в sql_standard, то ведущий знак считается применимым ко всем полям (но только если нет дополнительных знаков). В противном случае используется традиционная интерпретация Tantor SE. Чтобы избежать неоднозначности, рекомендуется добавить явный знак к каждому полю, если хотя бы одно поле отрицательное.

Значения полей могут иметь дробные части, например, '1.5 weeks' или '01:02:03.45'. Однако, поскольку интервал внутренне хранит только три целочисленных единицы (месяцы, дни, микросекунды), дробные единицы должны быть преобразованы в меньшие единицы. Дробные части единиц, больших чем месяцы, округляются до целого числа месяцев, например, '1.5 years' становится '1 year 6 mons'. Дробные части недель и дней вычисляются как целое число дней и микросекунд, предполагая 30 дней в месяце и 24 часа в сутках, например, '1.75 months' становится 1 mon 22 days 12:00:00. Только секунды будут отображаться как дробные при выводе.

Таблица 8.17 показывает некоторые примеры допустимого ввода для типа interval.

Таблица 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 секунд
P1Y2M3DT4H5M6SISO 8601 формат с обозначениями: тот же смысл, что и выше
P0001-02-03T04:05:06ISO 8601 альтернативный формат: тот же смысл, что и выше

Внутренне значения типа interval хранятся в виде месяцев, дней и микросекунд. Это делается потому, что количество дней в месяце может варьироваться, а день может иметь 23 или 25 часов, если применяется корректировка на переход на летнее время. Поля месяцев и дней являются целыми числами, в то время как поле микросекунд может хранить дробные секунды. Поскольку интервалы обычно создаются из постоянных строк или путем вычитания timestamp, этот метод хранения хорошо работает в большинстве случаев, но может вызывать неожиданные результаты:

SELECT EXTRACT(hours from '80 minutes'::interval);
 date_part
-----------
         1

SELECT EXTRACT(days from '80 hours'::interval);
 date_part
-----------
         0

Функции justify_days и justify_hours доступны для корректировки дней и часов, которые выходят за пределы их нормальных диапазонов.

8.5.5. Вывод интервала

Формат вывода типа интервал можно установить в один из четырех стилей: sql_standard, postgres, postgres_verbose или iso_8601, используя команду SET intervalstyle. По умолчанию используется формат postgres. Примеры каждого стиля вывода приведены в таблице Таблица 8.18.

Стиль sql_standard создает вывод, соответствующий спецификации стандарта SQL для строковых литералов интервалов, если значение интервала соответствует ограничениям стандарта (только год-месяц или только день-время, без смешивания положительных и отрицательных компонентов). В противном случае вывод выглядит как стандартная строка литерала год-месяц, за которой следует строка литерала день-время, с явными знаками, добавленными для разрешения смешанных интервалов со знаками.

Вывод в стиле postgres соответствует выводу релизов Tantor SE до версии 8.4, когда параметр DateStyle был установлен в значение ISO.

Вывод стиля postgres_verbose соответствует выводу релизов Tantor SE до версии 8.4, когда параметр DateStyle был установлен на не-ISO вывод.

Результат работы стиля iso_8601 соответствует формату с обозначениями, описанному в разделе 4.4.3.2 стандарта ISO 8601.

Таблица 8.18. Примеры стиля вывода интервалов

Спецификация стиляИнтервал год-месяцИнтервал день-времяСмешанный интервал
sql_standard1-23 4:05:06-1-2 +3 -4:05:06
postgres1 год 2 месяца3 дня 04:05:06-1 год -2 месяца +3 дня -04:05:06
postgres_verbose@ 1 год 2 месяца@ 3 дня 4 часа 5 минут 6 секунд@ 1 год 2 месяца -3 дня 4 часа 5 минут 6 секунд назад
iso_8601P1Y2MP3DT4H5M6SP-1Y-2M3D​T-4H-5M-6S