Movatterモバイル変換

8.5.1. Date/Time Input

8.5.2. Date/Time Output

8.5.3. Time Zones

8.5.4. Interval Input

8.5.5. Interval Output

Table 8.9. Date/Time Types

Note

The SQL standard requires that writing justtimestamp be equivalent totimestamp without time zone, andPostgres Pro honors that behavior.timestamptz is accepted as an abbreviation fortimestamp with time zone; this is aPostgres Pro extension.

Date and time input is accepted in almost any reasonable format, including ISO 8601,SQL-compatible, traditionalPOSTGRES, 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 theDateStyle parameter toMDY to select month-day-year interpretation,DMY to select day-month-year interpretation, orYMD to select year-month-day interpretation.

Postgres Pro is more flexible in handling date/time input than theSQL standard requires. SeeAppendix 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 toSection 4.1.2.7 for more information.SQL requires the following syntax

type [ (p) ] 'value'

wherep is an optional precision specification giving the number of fractional digits in the seconds field. Precision can be specified fortime,timestamp, andinterval 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), traditionalPOSTGRES (Unixdate format), or German. The default is theISO format. (TheSQL 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 thedate andtime types is generally only the date or time part in accordance with the given examples. However, thePOSTGRES style outputs date-only values inISO format.

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

In theISO 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 ashh (hours only) if it is an integral number of hours, else ashh:mm if it is an integral number of minutes, else ashh: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 orhhmm).

The date/time style can be selected by the user using theSET datestyle command, theDateStyle parameter in thepostgresql.conf configuration file, or thePGDATESTYLE environment variable on the server or client.

The formatting functionto_char (seeSection 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.Postgres Pro 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.

Postgres Pro endeavors to be compatible with theSQL standard definitions for typical usage. However, theSQL 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 donot recommend using the typetime with time zone (though it is supported byPostgres Pro for legacy applications and for compliance with theSQL standard).Postgres Pro assumes your local time zone for any type containing only date or time.

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

Postgres Pro 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). So2014-06-04 12:00 EDT specifies that same time instant. But2014-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 MoscowMSK has meant UTC+3 in some years and UTC+4 in others.Postgres Pro interprets such abbreviations according to whatever they meant (or had most recently meant) on the specified date; but, as with theEST 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 fromPostgreSQL 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 (seeSection B.4).

TheTimeZone configuration parameter can be set in the filepostgresql.conf, or in any of the other standard ways described inChapter 18. There are also some special ways to set it:

interval values can be written using the following verbose syntax:

[@]quantityunit [quantityunit...] [direction]

wherequantity is a number (possibly signed);unit ismicrosecond,millisecond,second,minute,hour,day,week,month,year,decade,century,millennium, or abbreviations or plurals of these units;direction can beago 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, ifIntervalStyle is set topostgres_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 theSQL standard, and are used for output whenIntervalStyle is set tosql_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:

Pquantityunit [quantityunit ...] [ T [quantityunit ...]]

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

In the alternative format:

P [years-months-days] [ Thours:minutes:seconds]

the string must begin withP, and aT 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 afields specification, or when assigning a string to an interval column that was defined with afields specification, the interpretation of unmarked quantities depends on thefields. For exampleINTERVAL '1' YEAR is read as 1 year, whereasINTERVAL '1' means 1 second. Also, field values“to the right” of the least significant field allowed by thefields specification are silently discarded. For example, writingINTERVAL '1 day 2:03:04' HOUR TO MINUTE results in dropping the seconds field, but not the day field.

According to theSQL 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.Postgres Pro 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. IfIntervalStyle is set tosql_standard then a leading sign is considered to apply to all fields (but only if no additional signs appear). Otherwise the traditionalPostgres Pro interpretation is used. To avoid ambiguity, it's recommended to attach an explicit sign to each field if any field is negative.

Internally,interval values are stored as three integral fields: months, days, and microseconds. These fields are kept separate because the number of days in a month varies, while a day can have 23 or 25 hours if a daylight savings time transition is involved. An interval input string that uses other units is normalized into this format, and then reconstructed in a standardized way for output, for example:

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

Here weeks, which are understood as“7 days”, have been kept separate, while the smaller and larger time units were combined and normalized.

Input field values can have fractional parts, for example'1.5 weeks' or'01:02:03.45'. However, becauseinterval internally stores only integral fields, fractional values must be converted into 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' becomes1 mon 22 days 12:00:00. Only seconds will ever be shown as fractional on output.

Table 8.17 shows some examples of validinterval input.

As previously explained,Postgres Pro storesinterval values as months, days, and microseconds. For output, the months field is converted to years and months by dividing by 12. The days field is shown as-is. The microseconds field is converted to hours, minutes, seconds, and fractional seconds. Thus months, minutes, and seconds will never be shown as exceeding the ranges 0–11, 0–59, and 0–59 respectively, while the displayed years, days, and hours fields can be quite large. (Thejustify_days andjustify_hours functions can be used if it is desirable to transpose large days or hours values into the next higher field.)

The output format of the interval type can be set to one of the four stylessql_standard,postgres,postgres_verbose, oriso_8601, using the commandSET intervalstyle. The default is thepostgres format.Table 8.18 shows examples of each output style.

Thesql_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 thepostgres style matches the output ofPostgreSQL releases prior to 8.4 when theDateStyle parameter was set toISO.

The output of thepostgres_verbose style matches the output ofPostgreSQL releases prior to 8.4 when theDateStyle parameter was set to non-ISO output.

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