8.5. 日期/時間類型 · PostgreSQL 中文文檔 9.3

# 8.5\. 日期/時間類型 [Table 8-9](#calibre_link-785)顯示了PostgreSQL 支持的SQL中所有日期和時間類型。這些數據類型上可以進行的操作在[Section 9.9](#calibre_link-786)中描述。日期是按照公歷計算的，甚至日歷之前的年份也介紹了（參閱[Section B.4](#calibre_link-125)獲取更多信息）。 **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_`的范圍對`timestamp`和`interval`類型是從0到6。 > **Note:** 如果`timestamp`數值是以8字節整數(目前的缺省)的方式存儲的，那么微秒的精度就可以在數值的全部范圍內都可以獲得。如果`timestamp` 數值是以雙精度浮點數(一個廢棄的編譯時的選項)的方式存儲的，那么有效精度會小于 6 。`timestamp`值是以 2000-01-01 午夜之前或之后的秒數存儲的。當`timestamp`值用浮點數實現時，微秒的精度是為那些在 2000-01-01 前后幾年的日期實現的，對于那些遠一些的日子，精度會下降。注意，使用浮點時間允許一個比上面顯示的更大的 `timestamp`值變化范圍：從4713BC到5874897AD。 > > 同一個編譯時選項也決定`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 ``` 注意如果同時指定了`_fields_`和`_p_`， `_fields_`必須包含`SECOND`，因為精度只應用于秒。 `time with time zone`類型是 SQL 標準定義的，但是完整定義的有些方面會導致有問題的用法。在大多數情況下，`date`, `time`, `timestamp without time zone`, 和`timestamp with time zone` 的組合就應該能提供一切應用需要的日期/時間的完整功能。 `abstime`和`reltime`類型是低分辨率類型，它們被用于系統內部。我們反對你在應用中使用這些類型，因為這些內部類型可能會在未來的版本里消失。 ## 8.5.1\. 日期/時間輸入日期和時間的輸入幾乎可以是任何合理的格式，包括 ISO-8601 格式、SQL-兼容格式、傳統POSTGRES格式、其它的形式。對于一些格式，日期輸入里的日、月、年可能會讓人迷惑，因此系統支持自定義這些字段的順序。把[DateStyle](#calibre_link-787)參數設置為`MDY`就按照"月-日-年"解析，設置為`DMY`就按照"日-月-年"解析，設置為`YMD`就按照"年-月-日"解析。 PostgreSQL在處理日期/時間輸入上比SQL 標準要求的更靈活。參閱[Appendix B](#calibre_link-121) 獲取關于日期/時間輸入的準確分析規則和可識別文本字段，包括月份、星期幾、時區。請記住任何日期或者時間的文本輸入需要由單引號包圍，就像一個文本字符串一樣。參考[Section 4.1.2.7](#calibre_link-788)獲取更多信息。 SQL要求使用下面的語法： ``` _type_ [ (_p_) ] '_value_' ``` 可選的精度聲明中的`_p_`是一個整數，表示在秒域中小數部分的位數，我們可以對`time`,`timestamp`,`interval`類型聲明精度。允許的精度在上面已經說明。如果在常量聲明中沒有聲明精度，缺省是文本值的精度。 ### 8.5.1.1\. 日期 [Table 8-10](#calibre_link-789)顯示了`date`類型可能的輸入方式。 **Table 8-10\. Date Input** | 例子 | 描述 | | --- | --- | | 1999-01-08 | ISO 8601格式(建議格式)，任何方式下都是 1999 年 1 月 8 號 | | January 8, 1999 | 在任何`datestyle`輸入模式下都無歧義 | | 1/8/1999 | 有歧義，在`MDY`下是一月八號；在`DMY`模式下是八月一日 | | 1/18/1999 | `MDY`模式下是一月十八日，其它模式下被拒絕 | | 01/02/03 | `MDY`模式下的 2003 年 1 月 2 日； `DMY`模式下的 2003 年 2 月 1 日； `YMD`模式下的 2001 年 2 月 3 日 | | 1999-Jan-08 | 任何模式下都是 1 月 8 日 | | Jan-08-1999 | 任何模式下都是 1 月 8 日 | | 08-Jan-1999 | 任何模式下都是 1 月 8 日 | | 99-Jan-08 | `YMD`模式下是 1 月 8 日，否則錯誤 | | 08-Jan-99 | 一月八日，除了在`YMD`模式下是錯誤的之外 | | Jan-08-99 | 一月八日，除了在`YMD`模式下是錯誤的之外 | | 19990108 | ISO 8601；任何模式下都是 1999 年 1 月 8 日 | | 990108 | ISO 8601；任何模式下都是 1999 年 1 月 8 日 | | 1999.008 | 年和年里的第幾天 | | J2451187 | 儒略日 | | January 8, 99 BC | 公元前 99 年 | ### 8.5.1.2\. 時間當日時間類型是`time [ (``_p_`) ] without time zone 和`time [ (``_p_`) ] with time zone。只寫`time`等效于`time without time zone`。這些類型的有效輸入由當日時間后面跟著可選的時區組成(參閱 [Table 8-11](#calibre_link-790)和[Table 8-12](#calibre_link-791))。如果在`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`的縮寫 | 參考[Section 8.5.3](#calibre_link-792)以獲取如何指定時區的更多信息。 ### 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`。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](#calibre_link-793)參數里的那個時區，然后使用這個`timezone`時區轉換成 UTC 。如果輸出一個`timestamp with time zone`，那么它總是從 UTC 轉換成當前的 `timezone`時區，并且顯示為該時區的本地時間。要看其它時區的該時間，要么修改`timezone`，要么使用`AT TIME ZONE`構造 (參閱[Section 9.9.3](#calibre_link-794))。在`timestamp without time zone`和`timestamp with time zone` 之間的轉換通常假設`timestamp without time zone`數值應該以 `timezone`本地時間的形式接受或者寫出。其它的時區可以用 `AT TIME ZONE`的方式為轉換聲明。 ### 8.5.1.4\. 特殊值 PostgreSQL為方便起見支持在 [Table 8-13](#calibre_link-795)里面顯示的幾個特殊輸入值。值`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](#calibre_link-796))。不過，請注意這些 SQL 函數_不是_ 被當作數據輸入字符串識別的。 ## 8.5.2\. 日期/時間輸出日期/時間類型的輸出格式可以設成 ISO 8601(默認)、SQL(Ingres)、傳統的POSTGRES(Unix date格式)或German四種風格之一。 SQL標準要求使用 ISO 8601 格式。"SQL"輸出格式的名字是歷史偶然。 [Table 8-14](#calibre_link-797)顯示了每種輸出風格的例子。 `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` | > **Note:** ISO 8601指定用大寫字母`T`分隔日期和時間。PostgreSQL 在輸入上接受這種格式，但是在輸出上使用一個空格而不是`T`，就像上面顯示的。這樣更易讀而且和RFC 3399或者其他的數據庫系統一致。如果聲明了 DMY 順序，那么在SQL和 POSTGRES 風格里，日期在月份之前出現，否則月份出現在日期之前(參閱[Section 8.5.1](#calibre_link-798) 看看這個設置如何影響對輸入值的解釋)。[Table 8-15](#calibre_link-799) 顯示了一個例子。 **Table 8-15\. 日期順序習慣** | `datestyle`設置 | 輸入順序 | 輸出樣例 | | --- | --- | --- | | `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`命令選取日期/時間的風格，也可以在配置文件`postgresql.conf` 中的[DateStyle](#calibre_link-787)參數中設置，或者在服務器或客戶端的 `PGDATESTYLE`環境變量中設置。我們也可以用格式化函數`to_char`(參見[Section 9.8](#calibre_link-800)) 來更靈活地控制時間/日期地輸出。 ## 8.5.3\. 時區時區和時區習慣不僅僅受地球幾何形狀的影響，還受到政治決定的影響。到了 19 世紀，全球的時區變得稍微標準化了些，但是還是易于遭受隨意的修改，部分是因為夏時制規則。PostgreSQL 使用廣泛使用的`zoneinfo`（Olson）時區信息數據庫有關歷史時區的規則。對于未來的時間，假設對于給定時區最近的規則將在未來繼續無期限的遵守。 PostgreSQL在典型應用中盡可能與SQL 的定義相兼容。但SQL標準在日期/時間類型和功能上有一些奇怪的混淆。兩個顯而易見的問題是： * `date`類型與時區沒有聯系，而`time`類型卻有或可以有。然而，現實世界的時區只有在與時間和日期都關聯時才有意義，因為時間偏移量(時差)可能因為實行類似夏時制這樣的制度而在一年里有所變化。 * 缺省的時區用一個數字常量表示與UTC的偏移(時差)。因此，當跨DST(夏時制)界限做日期/時間算術時，我們根本不可能把夏時制這樣的因素計算進去。為了克服這些困難，我們建議在使用時區的時候，使用那些同時包含日期和時間的日期/時間類型。我們建議_不要_使用`time with time zone`類型(盡管 PostgreSQL出于合理應用以及為了與SQL 標準兼容的考慮支持這個類型)。PostgreSQL 假設你用于任何類型的本地時區都只包含日期或時間(而不包含時區)。在系統內部，所有日期和時間都用全球統一時間UTC格式存儲，時間在發給客戶前端前由數據庫服務器根據[TimeZone](#calibre_link-793) 配置參數聲明的時區轉換成本地時間。 PostgreSQL允許你用三種方法指定時區： * 完整的時區名。例如`America/New_York`。所有可以識別的時區名在 `pg_timezone_names`視圖中列出(參見 [Section 47.71](#calibre_link-801))。PostgreSQL 使用廣泛使用的`zoneinfo`時區數據，所以這些時區名在其它軟件里也能被輕松的識別。 * 時區縮寫。例如`PST`。這種縮寫名通常只是定義了相對于 UTC 的偏移量，而前一種完整的時區名可能還隱含著一組夏時制轉換規則。所有可以識別的時區縮寫在`pg_timezone_abbrevs`視圖中列出(參見 [Section 47.70](#calibre_link-802))。你不能設置 [TimeZone](#calibre_link-793)或[log_timezone](#calibre_link-803) 配置參數為時區縮寫，但是你可以在日期/時間輸入值中結合`AT TIME ZONE` 操作符使用時區縮寫。 * 除完整的時區名及其縮寫之外，PostgreSQL還接受 POSIX 風格的 `_STD_``_offset_`或`_STD_``_offset_``_DST_` 格式的時區，其中的`_STD_`是時區縮寫、`_offset_` 是一個相對于 UTC 的小時偏移量、`_DST_`是一個可選的夏時制時區縮寫 (假定相對于給定的偏移量提前一小時)。例如，如果`EST5EDT`不是一個已識別的時區名，那么它將等同于美國東部時間。如果存在夏時制時區名是當前時區名，根據`zoneinfo` 時區數據庫的 `posixrules`條目中相同的夏時制事務規則，可以考慮使用這個特性。在一個PostgreSQL標準安裝中，`posixrules`與`US/Eastern` 相同，因此POSIX格式的時區聲明遵循USA夏時制規則。如果需要，可以通過替換`posixrules` 文件來調整該習慣。簡言之，這就是完整的時區名與時區縮寫之間的差異：時區縮寫總是代表一個相對于 UTC 的固定偏移量，然而大多數完整的時區名隱含著一個本地夏令時規則，因此就有可能有兩個相對于 UTC 的不同偏移量。需要警惕的是，由于沒有合理的時區縮寫檢查，POSIX格式的時區特點能導致靜默的偽輸入。例如，使用`SET TIMEZONE TO FOOBAR0`時，實際上系統使用的是一個很特別的UTC縮寫。另一個需要注意的是，在POSIX時區名中，積極的偏移用于_west_格林尼治位置。在其他地方，PostgreSQL遵循ISO-8601規定，即積極的時區偏移_east_格林威治。總體而言，PostgreSQL 8.2 版本以后時區名在所有情況下都是大小寫無關的。而之前的版本在某些情況下是大小寫敏感的。無論是完整的時區名還是時區縮寫都不是硬連接進服務器的，它們都是從安裝目錄下的 `.../share/timezone/`和`.../share/timezonesets/` 配置文件中獲取的(參見[Section B.3](#calibre_link-124))。可以在`postgresql.conf`文件里設置[TimeZone](#calibre_link-793) 配置參數，或者用任何其它在[Chapter 18](#calibre_link-500)描述的標準方法。除此之外，還有好幾種特殊方法可以設置它： * 使用SQL命令`SET TIME ZONE`為會話設置時區，這是`SET TIMEZONE TO`的一個可選的拼寫方式，更加兼容標準。 * 如果在客戶端設置了`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](#calibre_link-804) 設置為`postgres_verbose`，那么這個語法同樣用于間隔輸出。可以在沒有明確單位標記的情況下聲明天，小時，分鐘和秒。例如，`'1 12:59:10'` 等同于`'1 day 12 hours 59 min 10 sec'`。同樣，可以用一個破折號來聲明一個年和月的組合，例如`'200-10'`等同于 `'200 years 10 months'`。（事實上，SQL標準值允許短的格式，并且當`IntervalStyle`設置為`sql_standard`時，用于輸出）。要么使用4.4.3.2的"format with designators"，要么使用4.4.3.3的 "alternative format"，間隔值可以寫為ISO 8601的時間間隔。格式如下： ``` P _quantity_ _unit_ [ `_quantity_` `_unit_` ...] [ T [ `_quantity_` `_unit_` ...]] ``` 字符串必須以`P`開始，并且可以含有一個`T`用以指明一天中時間的格式。可用單位的縮寫在[Table 8-16](#calibre_link-805)有說明。可以忽略單位，也可以以任意順序聲明，但單位小于一天時必須在`T`之后。尤其`M`的含義依賴于它在`T`之前或之后。 **Table 8-16\. ISO 8601 間隔單位的縮寫** | 縮寫 | 含義 | | --- | --- | | Y | 年 | | M | 月（日期部分） | | W | 周 | | D | 日 | | H | 小時 | | M | 分鐘（時間部分） | | 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'`中負號同時應用于天和小時/分鐘/秒。PostgreSQL 允許字段有不同的標記，并且傳統上，文本表述中的每個字段會被認為是獨立標記的，因此在這個例子中的小時/分鐘/秒被認為是正值。如果`IntervalStyle`被設置為 `sql_standard`，那么前導標記被認為是應用于所有字段的（當然前提是沒有再出現其他標記），否則會使用傳統的PostgreSQL解釋。為了避免這種歧義，如果任何字段是負的，建議為每個字段附上一個明確的標記。 PostgreSQL內部，`interval`值被存儲為月，日，秒的格式，這是因為月中包含天數不同，并且如果進行了夏令時調整，那么一天可以有23或25小時。當秒字段可以存儲分數時，月和天字段可以是整數型。由于時間間隔通常是由常量字符串或`timestamp`減法來定義的，這種存儲方法在大多數情況下很有效。`justify_days`和`justify_hours` 函數可用于調整溢出正常范圍值的天和小時。在詳細的輸入格式，以及更緊湊的輸入格式中，字段值可以有小數部分，例如`'1.5 week'`或`'01:02:03.45'`。這種輸入被轉換成恰當的月，天和秒來存儲。由于這樣會產生小數的月或天，因此在低階字段中引入了分數，使用1 month = 30 days 和 1 day = 24 hours的轉換。例如，`'1.5 month'` 即1個月15天。輸出中，只有秒可以寫成分數形式。 [Table 8-17](#calibre_link-806)中有一些有效的`interval`輸入的例子。 **Table 8-17\. 間隔輸入** | 示例 | 說明 | | --- | --- | | 1-2 | SQL標準格式：一年兩個月 | | 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 "縮寫格式":與上面相同含義 | ## 8.5.5\. 間隔輸出間隔類型的輸出格式可以用命令`SET intervalstyle`設置為下面四種類型： `sql_standard`，`postgres`，`postgres_verbose`或 `iso_8601`。默認是`postgres`格式， [Table 8-18](#calibre_link-807)中有每種格式的示例。 `sql_standard`格式產生的輸出結果符合SQL的間隔字符串標準，如果間隔值滿足標準的限制（無論只有年-月，或只有天-時間，沒有積極和消極的構成的混合）。否則輸出類似一個標準年-月文本字符串后跟有一個天-時間文本字符串，帶有添加明確標記的消除歧義混合信號的時間間隔。當參數[DateStyle](#calibre_link-787)設置為`ISO`時， `postgres`格式的輸出與PostgreSQL 8.4之前的版本一致。當參數`DateStyle`設置為非-`ISO`， `postgres_verbose`格式的輸出與PostgreSQL 8.4之前的版本一致。 `iso_8601`格式的輸出與ISO 8601標準4.4.3.2節中的"format with designators"一致。 **Table 8-18\. 間隔輸出格式示例** | 格式 | 年-月間隔 | 天-時間間隔 | 混合間隔 | | --- | --- | --- | --- | | `sql_standard` | 1-2 | 3 4:05:06 | -1-2 +3 -4:05:06 | | `postgres` | 1 年 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_8601` | P1Y2M | P3DT4H5M6S | P-1Y-2M3DT-4H-5M-6S |