В postgresql существует тип данных для работы со временем

Table 8.9. Date/Time Types

Note

The SQL standard requires that writing just timestamp be equivalent to timestamp without time zone, and PostgreSQL honors that behavior. timestamptz is accepted as an abbreviation for timestamp with time zone; this is a PostgreSQL extension.

Date and time input is accepted in almost any reasonable format, including ISO 8601, SQL-compatible, traditional POSTGRES, and others. For some formats, ordering of day, month, and year in date input is ambiguous and there is support for specifying the expected ordering of these fields. Set the DateStyle parameter to MDY to select month-day-year interpretation, DMY to select day-month-year interpretation, or YMD to select year-month-day interpretation.

PostgreSQL is more flexible in handling date/time input than the SQL standard requires. See Appendix B for the exact parsing rules of date/time input and for the recognized text fields including months, days of the week, and time zones.

Remember that any date or time literal input needs to be enclosed in single quotes, like text strings. Refer to Section 4.1.2.7 for more information. SQL requires the following syntax

type [ (p) ] 'value'

where p is an optional precision specification giving the number of fractional digits in the seconds field. Precision can be specified for time, timestamp, and interval types, and can range from 0 to 6. If no precision is specified in a constant specification, it defaults to the precision of the literal value (but not more than 6 digits).

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'

The output format of the date/time types can be set to one of the four styles ISO 8601, SQL (Ingres), traditional POSTGRES (Unix date format), or German. The default is the ISO format. (The SQL standard requires the use of the ISO 8601 format. The name of the “SQL” output format is a historical accident.) Table 8.14 shows examples of each output style. The output of the date and time types is generally only the date or time part in accordance with the given examples. However, the POSTGRES style outputs date-only values in ISO format.

In the SQL and POSTGRES styles, day appears before month if DMY field ordering has been specified, otherwise month appears before day. (See Section 8.5.1 for how this setting also affects interpretation of input values.) Table 8.15 shows examples.

In the ISO style, the time zone is always shown as a signed numeric offset from UTC, with positive sign used for zones east of Greenwich. The offset will be shown as hh (hours only) if it is an integral number of hours, else as hh:mm if it is an integral number of minutes, else as hh:mm:ss. (The third case is not possible with any modern time zone standard, but it can appear when working with timestamps that predate the adoption of standardized time zones.) In the other date styles, the time zone is shown as an alphabetic abbreviation if one is in common use in the current zone. Otherwise it appears as a signed numeric offset in ISO 8601 basic format (hh or hhmm).

The date/time style can be selected by the user using the SET datestyle command, the DateStyle parameter in the postgresql.conf configuration file, or the PGDATESTYLE environment variable on the server or client.

The formatting function to_char (see Section 9.8) is also available as a more flexible way to format date/time output.

Time zones, and time-zone conventions, are influenced by political decisions, not just earth geometry. Time zones around the world became somewhat standardized during the 1900s, but continue to be prone to arbitrary changes, particularly with respect to daylight-savings rules. PostgreSQL uses the widely-used IANA (Olson) time zone database for information about historical time zone rules. For times in the future, the assumption is that the latest known rules for a given time zone will continue to be observed indefinitely far into the future.

PostgreSQL endeavors to be compatible with the SQL standard definitions for typical usage. However, the SQL standard has an odd mix of date and time types and capabilities. Two obvious problems are:

To address these difficulties, we recommend using date/time types that contain both date and time when using time zones. We do not recommend using the type time with time zone (though it is supported by PostgreSQL for legacy applications and for compliance with the SQL standard). PostgreSQL assumes your local time zone for any type containing only date or time.

All timezone-aware dates and times are stored internally in UTC. They are converted to local time in the zone specified by the TimeZone configuration parameter before being displayed to the client.

PostgreSQL allows you to specify time zones in three different forms:

In short, this is the difference between abbreviations and full names: abbreviations represent a specific offset from UTC, whereas many of the full names imply a local daylight-savings time rule, and so have two possible UTC offsets. As an example, 2014-06-04 12:00 America/New_York represents noon local time in New York, which for this particular date was Eastern Daylight Time (UTC-4). So 2014-06-04 12:00 EDT specifies that same time instant. But 2014-06-04 12:00 EST specifies noon Eastern Standard Time (UTC-5), regardless of whether daylight savings was nominally in effect on that date.

To complicate matters, some jurisdictions have used the same timezone abbreviation to mean different UTC offsets at different times; for example, in Moscow MSK has meant UTC+3 in some years and UTC+4 in others. PostgreSQL interprets such abbreviations according to whatever they meant (or had most recently meant) on the specified date; but, as with the EST example above, this is not necessarily the same as local civil time on that date.

In all cases, timezone names and abbreviations are recognized case-insensitively. (This is a change from PostgreSQL versions prior to 8.2, which were case-sensitive in some contexts but not others.)

Neither timezone names nor abbreviations are hard-wired into the server; they are obtained from configuration files stored under .../share/timezone/ and .../share/timezonesets/ of the installation directory (see Section B.4).

The TimeZone configuration parameter can be set in the file postgresql.conf, or in any of the other standard ways described in Chapter 20. There are also some special ways to set it:

interval values can be written using the following verbose syntax:

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

where quantity is a number (possibly signed); unit is microsecond, millisecond, second, minute, hour, day, week, month, year, decade, century, millennium, or abbreviations or plurals of these units; direction can be ago or empty. The at sign (@) is optional noise. The amounts of the different units are implicitly added with appropriate sign accounting. ago negates all the fields. This syntax is also used for interval output, if IntervalStyle is set to postgres_verbose.

Quantities of days, hours, minutes, and seconds can be specified without explicit unit markings. For example, '1 12:59:10' is read the same as '1 day 12 hours 59 min 10 sec'. Also, a combination of years and months can be specified with a dash; for example '200-10' is read the same as '200 years 10 months'. (These shorter forms are in fact the only ones allowed by the SQL standard, and are used for output when IntervalStyle is set to sql_standard.)

Interval values can also be written as ISO 8601 time intervals, using either the “format with designators” of the standard’s section 4.4.3.2 or the “alternative format” of section 4.4.3.3. The format with designators looks like this:

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

The string must start with a P, and may include a T that introduces the time-of-day units. The available unit abbreviations are given in Table 8.16. Units may be omitted, and may be specified in any order, but units smaller than a day must appear after T. In particular, the meaning of M depends on whether it is before or after T.

In the alternative format:

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

the string must begin with P, and a T separates the date and time parts of the interval. The values are given as numbers similar to ISO 8601 dates.

When writing an interval constant with a fields specification, or when assigning a string to an interval column that was defined with a fields specification, the interpretation of unmarked quantities depends on the fields. For example INTERVAL '1' YEAR is read as 1 year, whereas INTERVAL '1' means 1 second. Also, field values “to the right” of the least significant field allowed by the fields specification are silently discarded. For example, writing INTERVAL '1 day 2:03:04' HOUR TO MINUTE results in dropping the seconds field, but not the day field.

According to the SQL standard all fields of an interval value must have the same sign, so a leading negative sign applies to all fields; for example the negative sign in the interval literal '-1 2:03:04' applies to both the days and hour/minute/second parts. PostgreSQL allows the fields to have different signs, and traditionally treats each field in the textual representation as independently signed, so that the hour/minute/second part is considered positive in this example. If IntervalStyle is set to sql_standard then a leading sign is considered to apply to all fields (but only if no additional signs appear). Otherwise the traditional PostgreSQL interpretation is used. To avoid ambiguity, it’s recommended to attach an explicit sign to each field if any field is negative.

Field values can have fractional parts: for example, '1.5 weeks' or '01:02:03.45'. However, because interval internally stores only three integer units (months, days, microseconds), fractional units must be spilled to smaller units. Fractional parts of units greater than months are rounded to be an integer number of months, e.g. '1.5 years' becomes '1 year 6 mons'. Fractional parts of weeks and days are computed to be an integer number of days and microseconds, assuming 30 days per month and 24 hours per day, e.g., '1.75 months' becomes 1 mon 22 days 12:00:00. Only seconds will ever be shown as fractional on output.

Table 8.17 shows some examples of valid interval input.

Internally interval values are stored as months, days, and microseconds. This is done because the number of days in a month varies, and a day can have 23 or 25 hours if a daylight savings time adjustment is involved. The months and days fields are integers while the microseconds field can store fractional seconds. Because intervals are usually created from constant strings or timestamp subtraction, this storage method works well in most cases, but can cause unexpected results:

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

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

Functions justify_days and justify_hours are available for adjusting days and hours that overflow their normal ranges.

The output format of the interval type can be set to one of the four styles sql_standard, postgres, postgres_verbose, or iso_8601, using the command SET intervalstyle. The default is the postgres format. Table 8.18 shows examples of each output style.

The sql_standard style produces output that conforms to the SQL standard’s specification for interval literal strings, if the interval value meets the standard’s restrictions (either year-month only or day-time only, with no mixing of positive and negative components). Otherwise the output looks like a standard year-month literal string followed by a day-time literal string, with explicit signs added to disambiguate mixed-sign intervals.

The output of the postgres style matches the output of PostgreSQL releases prior to 8.4 when the DateStyle parameter was set to ISO.

The output of the postgres_verbose style matches the output of PostgreSQL releases prior to 8.4 when the DateStyle parameter was set to non-ISO output.

The output of the iso_8601 style matches the “format with designators” described in section 4.4.3.2 of the ISO 8601 standard.

Table 8.9. Date/Time Types

Note

The SQL standard requires that writing just timestamp be equivalent to timestamp without time zone, and PostgreSQL honors that behavior. timestamptz is accepted as an abbreviation for timestamp with time zone; this is a PostgreSQL extension.

Date and time input is accepted in almost any reasonable format, including ISO 8601, SQL-compatible, traditional POSTGRES, and others. For some formats, ordering of day, month, and year in date input is ambiguous and there is support for specifying the expected ordering of these fields. Set the DateStyle parameter to MDY to select month-day-year interpretation, DMY to select day-month-year interpretation, or YMD to select year-month-day interpretation.

PostgreSQL is more flexible in handling date/time input than the SQL standard requires. See Appendix B for the exact parsing rules of date/time input and for the recognized text fields including months, days of the week, and time zones.

Remember that any date or time literal input needs to be enclosed in single quotes, like text strings. Refer to Section 4.1.2.7 for more information. SQL requires the following syntax

type [ (p) ] 'value'

where p is an optional precision specification giving the number of fractional digits in the seconds field. Precision can be specified for time, timestamp, and interval types, and can range from 0 to 6. If no precision is specified in a constant specification, it defaults to the precision of the literal value (but not more than 6 digits).

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'

The output format of the date/time types can be set to one of the four styles ISO 8601, SQL (Ingres), traditional POSTGRES (Unix date format), or German. The default is the ISO format. (The SQL standard requires the use of the ISO 8601 format. The name of the “SQL” output format is a historical accident.) Table 8.14 shows examples of each output style. The output of the date and time types is generally only the date or time part in accordance with the given examples. However, the POSTGRES style outputs date-only values in ISO format.

In the SQL and POSTGRES styles, day appears before month if DMY field ordering has been specified, otherwise month appears before day. (See Section 8.5.1 for how this setting also affects interpretation of input values.) Table 8.15 shows examples.

In the ISO style, the time zone is always shown as a signed numeric offset from UTC, with positive sign used for zones east of Greenwich. The offset will be shown as hh (hours only) if it is an integral number of hours, else as hh:mm if it is an integral number of minutes, else as hh:mm:ss. (The third case is not possible with any modern time zone standard, but it can appear when working with timestamps that predate the adoption of standardized time zones.) In the other date styles, the time zone is shown as an alphabetic abbreviation if one is in common use in the current zone. Otherwise it appears as a signed numeric offset in ISO 8601 basic format (hh or hhmm).

The date/time style can be selected by the user using the SET datestyle command, the DateStyle parameter in the postgresql.conf configuration file, or the PGDATESTYLE environment variable on the server or client.

The formatting function to_char (see Section 9.8) is also available as a more flexible way to format date/time output.

Time zones, and time-zone conventions, are influenced by political decisions, not just earth geometry. Time zones around the world became somewhat standardized during the 1900s, but continue to be prone to arbitrary changes, particularly with respect to daylight-savings rules. PostgreSQL uses the widely-used IANA (Olson) time zone database for information about historical time zone rules. For times in the future, the assumption is that the latest known rules for a given time zone will continue to be observed indefinitely far into the future.

PostgreSQL endeavors to be compatible with the SQL standard definitions for typical usage. However, the SQL standard has an odd mix of date and time types and capabilities. Two obvious problems are:

To address these difficulties, we recommend using date/time types that contain both date and time when using time zones. We do not recommend using the type time with time zone (though it is supported by PostgreSQL for legacy applications and for compliance with the SQL standard). PostgreSQL assumes your local time zone for any type containing only date or time.

All timezone-aware dates and times are stored internally in UTC. They are converted to local time in the zone specified by the TimeZone configuration parameter before being displayed to the client.

PostgreSQL allows you to specify time zones in three different forms:

In short, this is the difference between abbreviations and full names: abbreviations represent a specific offset from UTC, whereas many of the full names imply a local daylight-savings time rule, and so have two possible UTC offsets. As an example, 2014-06-04 12:00 America/New_York represents noon local time in New York, which for this particular date was Eastern Daylight Time (UTC-4). So 2014-06-04 12:00 EDT specifies that same time instant. But 2014-06-04 12:00 EST specifies noon Eastern Standard Time (UTC-5), regardless of whether daylight savings was nominally in effect on that date.

To complicate matters, some jurisdictions have used the same timezone abbreviation to mean different UTC offsets at different times; for example, in Moscow MSK has meant UTC+3 in some years and UTC+4 in others. PostgreSQL interprets such abbreviations according to whatever they meant (or had most recently meant) on the specified date; but, as with the EST example above, this is not necessarily the same as local civil time on that date.

In all cases, timezone names and abbreviations are recognized case-insensitively. (This is a change from PostgreSQL versions prior to 8.2, which were case-sensitive in some contexts but not others.)

Neither timezone names nor abbreviations are hard-wired into the server; they are obtained from configuration files stored under .../share/timezone/ and .../share/timezonesets/ of the installation directory (see Section B.4).

The TimeZone configuration parameter can be set in the file postgresql.conf, or in any of the other standard ways described in Chapter 19. There are also some special ways to set it:

interval values can be written using the following verbose syntax:

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

where quantity is a number (possibly signed); unit is microsecond, millisecond, second, minute, hour, day, week, month, year, decade, century, millennium, or abbreviations or plurals of these units; direction can be ago or empty. The at sign (@) is optional noise. The amounts of the different units are implicitly added with appropriate sign accounting. ago negates all the fields. This syntax is also used for interval output, if IntervalStyle is set to postgres_verbose.

Quantities of days, hours, minutes, and seconds can be specified without explicit unit markings. For example, '1 12:59:10' is read the same as '1 day 12 hours 59 min 10 sec'. Also, a combination of years and months can be specified with a dash; for example '200-10' is read the same as '200 years 10 months'. (These shorter forms are in fact the only ones allowed by the SQL standard, and are used for output when IntervalStyle is set to sql_standard.)

Interval values can also be written as ISO 8601 time intervals, using either the “format with designators” of the standard’s section 4.4.3.2 or the “alternative format” of section 4.4.3.3. The format with designators looks like this:

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

The string must start with a P, and may include a T that introduces the time-of-day units. The available unit abbreviations are given in Table 8.16. Units may be omitted, and may be specified in any order, but units smaller than a day must appear after T. In particular, the meaning of M depends on whether it is before or after T.

In the alternative format:

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

the string must begin with P, and a T separates the date and time parts of the interval. The values are given as numbers similar to ISO 8601 dates.

When writing an interval constant with a fields specification, or when assigning a string to an interval column that was defined with a fields specification, the interpretation of unmarked quantities depends on the fields. For example INTERVAL '1' YEAR is read as 1 year, whereas INTERVAL '1' means 1 second. Also, field values “to the right” of the least significant field allowed by the fields specification are silently discarded. For example, writing INTERVAL '1 day 2:03:04' HOUR TO MINUTE results in dropping the seconds field, but not the day field.

According to the SQL standard all fields of an interval value must have the same sign, so a leading negative sign applies to all fields; for example the negative sign in the interval literal '-1 2:03:04' applies to both the days and hour/minute/second parts. PostgreSQL allows the fields to have different signs, and traditionally treats each field in the textual representation as independently signed, so that the hour/minute/second part is considered positive in this example. If IntervalStyle is set to sql_standard then a leading sign is considered to apply to all fields (but only if no additional signs appear). Otherwise the traditional PostgreSQL interpretation is used. To avoid ambiguity, it’s recommended to attach an explicit sign to each field if any field is negative.

Field values can have fractional parts: for example, '1.5 weeks' or '01:02:03.45'. However, because interval internally stores only three integer units (months, days, microseconds), fractional units must be spilled to smaller units. Fractional parts of units greater than months are truncated to be an integer number of months, e.g. '1.5 years' becomes '1 year 6 mons'. Fractional parts of weeks and days are computed to be an integer number of days and microseconds, assuming 30 days per month and 24 hours per day, e.g., '1.75 months' becomes 1 mon 22 days 12:00:00. Only seconds will ever be shown as fractional on output.

Table 8.17 shows some examples of valid interval input.

Internally interval values are stored as months, days, and microseconds. This is done because the number of days in a month varies, and a day can have 23 or 25 hours if a daylight savings time adjustment is involved. The months and days fields are integers while the microseconds field can store fractional seconds. Because intervals are usually created from constant strings or timestamp subtraction, this storage method works well in most cases, but can cause unexpected results:

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

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

Functions justify_days and justify_hours are available for adjusting days and hours that overflow their normal ranges.

The output format of the interval type can be set to one of the four styles sql_standard, postgres, postgres_verbose, or iso_8601, using the command SET intervalstyle. The default is the postgres format. Table 8.18 shows examples of each output style.

The sql_standard style produces output that conforms to the SQL standard’s specification for interval literal strings, if the interval value meets the standard’s restrictions (either year-month only or day-time only, with no mixing of positive and negative components). Otherwise the output looks like a standard year-month literal string followed by a day-time literal string, with explicit signs added to disambiguate mixed-sign intervals.

The output of the postgres style matches the output of PostgreSQL releases prior to 8.4 when the DateStyle parameter was set to ISO.

The output of the postgres_verbose style matches the output of PostgreSQL releases prior to 8.4 when the DateStyle parameter was set to non-ISO output.

The output of the iso_8601 style matches the “format with designators” described in section 4.4.3.2 of the ISO 8601 standard.

8.5.1.1. Dates

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

8.5.1.2. Times

Типы time [ (p) ] without time zone суток: время [(p)] без часового пояса и 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.5.3 для получения дополнительной информации о том, как указать часовые пояса.

8.5.1.3.Штампы времени

Допустимый ввод для типов отметок времени состоит из конкатенации даты и времени, за которыми следует необязательный часовой пояс, за которым следует необязательный AD или BC . (В качестве альтернативы, AD / BC может стоять перед часовым поясом, но это не является предпочтительным порядком.) Таким образом:

1999-01-08 04:05:06

and:

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

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

January 8 04:05:06 1999 PST

is supported.

Стандарт 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 time zone , PostgreSQL будет молча игнорировать любое указание часового пояса. Таким образом, результирующее значение получается из полей даты / времени во входном значении и не корректируется по часовому поясу.

Для timestamp with time zone внутренне сохраненное значение всегда находится в формате UTC (универсальное скоординированное время, традиционно известное как среднее время по Гринвичу, 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.Специальные значения

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

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

Table 8-9. Типы даты/времени

Note: Стандарт SQL требует, чтобы написание просто timestamp
было эквивалентно timestamp without time zone и
PostgreSQL следует стандарту.
(Версии до 7.3 считали, что timestamp with time zone.)
timestamptz допускается как сокращение для
timestamp with time zone; это расширенное поведение
PostgreSQL.

Note: Если значения timestamp хранятся как восьмибайтное целое число
(по умолчанию это так), то в пределах всего диапазона значений достигается
точность в одну микросекунду. Если значения timestamp хранятся
как число с плавающей запятой двойной точности (в случае выбора устаревшей
опции при компиляции), то эффективное ограничение на точность может быть
меньше 6. Значения timestamp хранятся как количество секунд
перед или после 2000-01-01. Когда значения timestamp
реализуются с использованием чисел с плавающей точкой, микросекундная
точность достигается для дат, которые находятся внутри отрезка, начинающегося
с 2000-01-01, но эта точность снижается для дат вне этого отрезка.
Обратите внимание, что значения timestamp, использующие
плавающую точку позволяют работать с большим диапазоном значений,
чем указано выше: от 4713 BC до 5874897 AD.

Та же опция при
компиляции также определяет будут ли значения time
interval храниться как числа с плавающей точкой или
как восьмибайтные целые числа. В случае чисел с плавающей точкой,
бОльшие значения interval имеют меньшую точность
из-за увеличения размера самого интервала.

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

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

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

Помните, что любые вводимые значения даты или времени необходимо
заключать в одиночные кавычки, как и текстовые строки. Больше
информации можно найти в Section 4.1.2.7.
SQL требует следующего синтаксиса

тип [ (p) ] 'значение'

где p является необязательной
спецификацией точности, которая задаётся целым числом,
соответствующим количеству дробрых разрядов во втором поле.
Точность может быть задана
для типов time, timestamp и
interval. Допустимые значения были рассмотрены выше.
Если точность в спецификации константы не указана, то она
устанавливается в значение по умолчанию для литеральных значений.

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'

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

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

В стилях SQL и POSTGRES, день идёт перед месяцем, если
быд задан порядок полей DMY, в противном случае месяц следует перед днём.
(См. Section 8.5.1
о том как эта настройка также отказывает эффект на интерпретацию вводимых
значений.) В Table 8-15 показан
пример.

Пользователь может выбрать нужные ему стили даты/времени с
помощью команды SET datestyle, параметра DateStyle в конфигурационном файле
postgresql.conf или с установив переменную
окружения PGDATESTYLE на сервере или клиенте.
Функция форматирования to_char
(см. Section 9.8) также может быть
использована как более гибкий способ форматирования выводимых
значений даты/времени.

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

Часовые пояса и соглашения по часовым поясам зависят не только
геометрии планеты, но и от политического территориального деления.
Часовые пояса во всём мире стали чем-то стандартным, начиная с
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.

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

Значения типа 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.

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

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.

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

Формат вывода значений типа 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.

8.5.6. Некоторые подробности по датам

PostgreSQL использует для всех вычислений
даты/времени Юлианский календарь. У него есть прекрасное свойство
вычислять любую дату, которая следует за годом 4713 до н.э.,
потому что используется длина года, равная 365.2425 дням.

Соглашения по датам, которые использовались до 19-го века интересны,
но не позволяют целостно использовать их при кодировании обработки
даты/времени.