PostgreSQL 支援全部SQL日期和時間型別,如表 8.9所示。這些資料型別可用的操作在第 9.9 節中進行了描述。日期的計算遵循公曆,即使是在該曆法引入之前的年份(有關更多資訊,請參閱第 B.6 節)。
表 8.9. 日期/時間型別
名稱 | 儲存大小 | 描述 | 最小值 | 最大值 | 解析度 |
---|---|---|---|---|---|
timestamp [ ( |
8 位元組 | 日期和時間(無時區) | 公元前 4713 年 | 公元 294276 年 | 1 微秒 |
timestamp [ ( |
8 位元組 | 日期和時間(帶時區) | 公元前 4713 年 | 公元 294276 年 | 1 微秒 |
date |
4 位元組 | 日期(無時間) | 公元前 4713 年 | 公元 5874897 年 | 1 天 |
time [ ( |
8 位元組 | 時間(無日期) | 00:00:00 | 24:00:00 | 1 微秒 |
time [ ( |
12 位元組 | 時間(無日期,帶時區) | 00:00:00+1559 | 24:00:00-1559 | 1 微秒 |
interval [ |
16 位元組 | 時間間隔 | -178000000 年 | 178000000 年 | 1 微秒 |
SQL 標準要求僅寫 timestamp
等同於 timestamp without time zone
,並且 PostgreSQL 遵循此行為。timestamptz
是 timestamp with time zone
的縮寫;這是 PostgreSQL 的一個擴充套件。
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
請注意,如果同時指定了 fields
和 p
,則 fields
必須包含 SECOND
,因為精度僅適用於秒。
型別 time with time zone
由 SQL 標準定義,但其定義表現出的特性使其用途可疑。在大多數情況下,date
、time
、timestamp without time zone
和 timestamp with time zone
的組合應該能提供任何應用程式所需的完整日期/時間功能。
日期和時間輸入幾乎可以用任何合理的格式接受,包括 ISO 8601、SQL-相容、傳統 POSTGRES 等。對於某些格式,日期輸入中日、月、年的順序可能存在歧義,並且支援指定這些欄位的預期順序。將 DateStyle 引數設定為 MDY
以選擇月-日-年解釋,設定為 DMY
以選擇日-月-年解釋,或設定為 YMD
以選擇年-月-日解釋。
PostgreSQL 在處理日期/時間輸入時比SQL標準要求更靈活。有關日期/時間輸入的精確解析規則以及識別的文字欄位(包括月份、星期幾和時區),請參閱附錄 B。
請記住,任何日期或時間字面量輸入都需要用單引號括起來,就像文字字串一樣。有關更多資訊,請參閱第 4.1.2.7 節。SQL要求以下語法
type
[ (p
) ] 'value
'
其中 p
是可選的精度說明,表示秒欄位中的小數位數。精度可以為 time
、timestamp
和 interval
型別指定,範圍為 0 到 6。如果在常量說明中未指定精度,則預設為字面值本身的精度(但最多為 6 位)。
表 8.10 顯示了 date
型別的一些可能輸入。
表 8.10. 日期輸入
示例: | 描述 |
---|---|
1999-01-08 | ISO 8601;任何模式下的 1 月 8 日(推薦格式) |
1999 年 1 月 8 日 | 在任何 datestyle 輸入模式下都無歧義 |
1/8/1999 | MDY 模式下的 1 月 8 日;DMY 模式下的 8 月 1 日 |
1/18/1999 | MDY 模式下的 1 月 18 日;其他模式下拒絕 |
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 | 1 月 8 日,在 YMD 模式下報錯 |
Jan-08-99 | 1 月 8 日,在 YMD 模式下報錯 |
19990108 | ISO 8601;任何模式下的 1999 年 1 月 8 日 |
990108 | ISO 8601;任何模式下的 1999 年 1 月 8 日 |
1999.008 | 年份和一年中的第幾天 |
J2451187 | 儒略日數 |
公元前 99 年 1 月 8 日 | 公元前 99 年 |
時間型別是 time [ (
和 p
) ] without time zonetime [ (
。p
) ] with time zonetime
本身等同於 time without time zone
。
這些型別有效輸入的格式是時間後跟一個可選的時區。(參見表 8.11 和 表 8.12。)如果為 time without time zone
的輸入指定了時區,它將被靜默忽略。您也可以指定一個日期,但它將被忽略,除非您使用了一個涉及夏令時規則的時區名稱,例如 America/New_York
。在這種情況下,指定日期是必需的,以便確定適用的是標準時間還是夏令時。相應的時區偏移量會記錄在 time with time zone
值中並按儲存的方式輸出;它不會根據當前活動時區進行調整。
表 8.11. 時間輸入
示例: | 描述 |
---|---|
04:05:06.789 |
ISO 8601 |
04:05:06 |
ISO 8601 |
04:05 |
ISO 8601 |
040506 |
ISO 8601 |
上午 04:05 |
與 04:05 相同;AM 不影響值 |
下午 04:05 |
與 16:05 相同;輸入小時必須 <= 12 |
04:05:06.789-8 |
ISO 8601,時區為 UTC 偏移量 |
04:05:06-08:00 |
ISO 8601,時區為 UTC 偏移量 |
04:05-08:00 |
ISO 8601,時區為 UTC 偏移量 |
040506-08 |
ISO 8601,時區為 UTC 偏移量 |
040506+0730 |
ISO 8601,帶小數小時時區的 UTC 偏移量 |
040506+07:30:00 |
指定到秒的 UTC 偏移量(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:00 |
PST 的 UTC 偏移量 |
-8:00 |
PST 的 UTC 偏移量(ISO 8601 擴充套件格式) |
-800 |
PST 的 UTC 偏移量(ISO 8601 基本格式) |
-8 |
PST 的 UTC 偏移量(ISO 8601 基本格式) |
zulu |
UTC 的軍事縮寫 |
z |
zulu 的簡寫(也在 ISO 8601 中) |
有關如何指定時區的資訊,請參閱第 8.5.3 節。
時間戳型別的有效輸入包括日期和時間的連線,後跟可選的時區,再後跟可選的 AD
或 BC
。(或者,AD
/BC
可以出現在時區之前,但這不推薦。)因此,
1999-01-08 04:05:06
和
1999-01-08 04:05:06 -8:00
是有效值,它們遵循ISO8601 標準。此外,通用格式
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(世界協調時間)。如果輸入字串中沒有指定時區,則假定它處於系統 TimeZone 引數指示的時區中,並使用 timezone
時區的偏移量轉換為 UTC。無論哪種情況,值都將內部儲存為 UTC,並且不會保留原始指定或假定的時區。
當 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
為轉換指定不同的時區。
PostgreSQL 支援幾個特殊的日期/時間輸入值以方便使用,如表 8.13 所示。infinity
和 -infinity
值在系統內部有特殊的表示,會原樣顯示;但其他值僅僅是符號縮寫,在讀取時會被轉換為普通的日期/時間值。(特別是,now
和相關字串一旦被讀取就會轉換為一個特定的時間值。)所有這些值在 SQL 命令中用作常量時都需要用單引號括起來。
表 8.13. 特殊日期/時間輸入
輸入字串 | 有效型別 | 描述 |
---|---|---|
epoch |
date , timestamp |
1970-01-01 00:00:00+00(Unix 系統零時) |
infinity |
date , timestamp , interval |
晚於所有其他時間戳 |
-infinity |
date , timestamp , interval |
早於所有其他時間戳 |
now |
date , time , timestamp |
當前事務的開始時間 |
today |
date , timestamp |
今天的午夜(00:00 ) |
tomorrow |
date , timestamp |
明天的午夜(00:00 ) |
yesterday |
date , timestamp |
昨天的午夜(00:00 ) |
allballs |
time |
00: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
更安全。
日期/時間型別的輸出格式可以設定為四種樣式之一:ISO 8601、SQL(Ingres)、傳統 POSTGRES(Unix date 格式)或德式。預設是ISO格式。(SQL標準要求使用 ISO 8601 格式。“SQL” 輸出格式的名稱是一個歷史巧合。)表 8.14 展示了每種輸出樣式的示例。date
和 time
型別的輸出通常僅是日期或時間部分,與給定的示例一致。但是,POSTGRES 樣式以ISO格式輸出僅日期值。
表 8.14. 日期/時間輸出樣式
樣式規範 | 描述 | 示例: |
---|---|---|
ISO |
ISO 8601,SQL 標準 | 1997-12-17 07:37:16-08 |
SQL |
傳統樣式 | 1997 年 12 月 17 日 07:37:16.00 PST |
Postgres |
原始樣式 | Wed Dec 17 07:37:16 1997 PST |
德文 |
區域樣式 | 1997 年 12 月 17 日 07:37:16.00 PST |
ISO 8601 指定使用大寫字母 T
來分隔日期和時間。PostgreSQL 在輸入時接受該格式,但在輸出時使用空格而不是 T
,如上所示。這是為了提高可讀性,並與 RFC 3339 以及其他一些資料庫系統保持一致。
在SQL和 POSTGRES 樣式中,如果指定了 DMY 欄位順序,則日期在前,月份在後;否則,月份在前,日期在後。(關於此設定如何影響輸入值的解釋,請參閱第 8.5.1 節。)表 8.15 顯示了示例。
表 8.15. 日期順序約定
datestyle 設定 |
輸入順序 | 示例輸出 |
---|---|---|
SQL, DMY |
日 /月 /年 |
1997 年 12 月 17 日 15:37:16.00 CET |
SQL, MDY |
月 /日 /年 |
1997 年 12 月 17 日 07:37:16.00 PST |
Postgres, DMY |
日 /月 /年 |
Wed 17 Dec 07:37:16 1997 PST |
在ISO樣式中,時區始終顯示為與 UTC 的帶符號數字偏移量,正號用於格林威治以東的時區。如果偏移量是整小時,則顯示為 hh
(僅小時),否則顯示為 hh
:mm
(整分鐘),否則顯示為 hh
:mm
:ss
。(第三種情況在任何現代時區標準下都不可能出現,但在處理早於標準化時區採用的時間戳時可能會出現。)在其他日期樣式中,如果當前區域有常用的字母縮寫,則時區顯示為字母縮寫。否則,它顯示為 ISO 8601 基本格式的帶符號數字偏移量(hh
或 hhmm
)。這些樣式中顯示的字母縮寫取自當前 TimeZone 執行時引數選擇的 IANA 時區資料庫條目;它們不受 timezone_abbreviations 設定的影響。
使用者可以使用 SET datestyle
命令、postgresql.conf
配置檔案中的 DateStyle 引數,或伺服器或客戶端上的 PGDATESTYLE
環境變數來選擇日期/時間樣式。
格式化函式 to_char
(參見第 9.8 節)也可作為更靈活的日期/時間輸出格式化方法。
時區和時區約定受到政治決策的影響,而不僅僅是地球幾何。PostgreSQL 使用廣泛使用的 IANA(Olson)時區資料庫來獲取歷史時區規則資訊。對於未來的時間,假定給定時區的最新已知規則將無限期地繼續遵守。
PostgreSQL 致力於與SQL典型用法的標準定義相容。然而,SQL標準包含混合了日期和時間型別以及功能。兩個明顯的問題是
雖然 date
型別不能關聯時區,但 time
型別可以。現實世界中的時區如果沒有與日期和時間相關聯,則意義不大,因為時區偏移量可能會因夏令時邊界而在一年中發生變化。
預設時區被指定為與UTC的固定數字偏移量。因此,在進行跨DST邊界的日期/時間算術時,無法適應夏令時。
為了解決這些困難,我們建議在使用時區時使用同時包含日期和時間的日期/時間型別。我們不推薦使用 time with time zone
型別(儘管 PostgreSQL 支援它以相容舊應用程式和SQL標準)。PostgreSQL 假定僅包含日期或時間的任何型別的本地時區。
所有帶時區的日期和時間都儲存在內部的UTC中。在顯示給客戶端之前,它們會使用 TimeZone 配置引數指定的時區轉換為本地時間。
PostgreSQL 允許您以三種不同的形式指定時區
完整的時區名稱,例如 America/New_York
。識別的時區名稱列在 pg_timezone_names
檢視中(參見第 53.34 節)。PostgreSQL 為此使用廣泛使用的 IANA 時區資料,因此其他軟體也識別相同的時區名稱。
時區縮寫,例如 PST
。這種指定僅定義了與 UTC 的特定偏移量,而完整的時區名稱可能暗示了一組夏令時轉換規則。識別的縮寫列在 pg_timezone_abbrevs
檢視中(參見第 53.33 節)。您不能將配置引數 TimeZone 或 log_timezone 設定為時區縮寫,但您可以在日期/時間輸入值和 AT TIME ZONE
運算子中使用縮寫。
除了時區名稱和縮寫之外,PostgreSQL 還接受 POSIX 風格的時區規範,如第 B.5 節中所述。此選項通常不優於使用命名時區,但如果不存在合適的 IANA 時區條目,則可能需要。
簡而言之,這是縮寫和全名之間的區別:縮寫代表與 UTC 的特定偏移量,而許多全名則暗示了本地夏令時規則,因此有兩種可能的 UTC 偏移量。例如,2014-06-04 12:00 America/New_York
代表紐約當地時間的下午 12 點,對於這個特定日期是東部夏令時(UTC-4)。因此,2014-06-04 12:00 EDT
指定了相同的時間點。但是 2014-06-04 12:00 EST
指定的是東部標準時間(UTC-5)的下午 12 點,而不考慮該日期是否名義上實行了夏令時。
POSIX 風格時區規範中的符號與 ISO-8601 日期時間值中的符號含義相反。例如,2014-06-04 12:00+04
的 POSIX 時區將是 UTC-4。
為了增加複雜性,一些司法管轄區在不同時間使用相同的時區縮寫表示不同的 UTC 偏移量;例如,在莫斯科,MSK
在某些年份表示 UTC+3,在另一些年份表示 UTC+4。PostgreSQL 根據給定日期該縮寫的含義(或最近的含義)來解釋此類縮寫;但是,如上面的 EST
示例所示,這不一定與該日期的當地民用時間相同。
總而言之,時區名稱和縮寫是大小寫不敏感的。(與 8.2 版本之前的 PostgreSQL 版本不同,後者在某些上下文中有大小寫敏感,在其他上下文則沒有。)
時區名稱和縮寫都不是硬編碼在伺服器中的;它們是從安裝目錄下的 .../share/timezone/
和 .../share/timezonesets/
中的配置檔案獲取的(參見第 B.4 節)。
配置引數 TimeZone 可以在 postgresql.conf
檔案中設定,或以第 19 章中描述的任何其他標準方式設定。還有一些特殊的設定方法
該SQL命令 SET TIME ZONE
設定會話的時區。這是 SET TIMEZONE TO
的另一種拼寫,具有更符合 SQL 規範的語法。
PGTZ
環境變數由 libpq 客戶端使用,以便在連線時向伺服器傳送 SET TIME ZONE
命令。
interval
值可以使用以下詳細語法編寫
[@]quantity
unit
[quantity
unit
...] [direction
]
其中 quantity
是一個數字(可能帶符號);unit
是 microsecond
、millisecond
、second
、minute
、hour
、day
、week
、month
、year
、decade
、century
、millennium
,或者這些單位的縮寫或複數形式;direction
可以是 ago
或空。at 符號(@
)是可選的噪聲。不同單位的數量會被隱式新增,並考慮適當的符號。ago
會否定所有欄位。此語法也用於時間間隔輸出,如果 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
時用於輸出。)
間隔值也可以使用 ISO 8601 時間間隔的格式來表示,可以使用標準第 4.4.3.2 節中的“帶指示符的格式”或第 4.4.3.3 節中的“備用格式”。帶指示符的格式如下所示。
Pquantity
unit
[quantity
unit
...] [ T [quantity
unit
...]]
字串必須以 P
開頭,並且可以選擇包含一個 T
來引入一天中的時間單位。可用的單位縮寫在 表 8.16 中給出。單位可以省略,並且可以按任何順序指定,但小於一天的單位必須出現在 T
之後。特別是,M
的含義取決於它是在 T
之前還是之後。
表 8.16. ISO 8601 間隔單位縮寫
縮寫 | 含義 |
---|---|
Y | 年 |
M | 月(日期部分) |
W | 周 |
D | 天 |
H | 營業時間 |
M | 分鐘(時間部分) |
S | 秒 |
備用格式中
P [years
-months
-days
] [ Thours
: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 解釋。為避免歧義,建議在任何欄位為負數時,為每個欄位附加一個顯式符號。
在內部,interval
值儲存為三個整數字段:月、天和微秒。這些欄位是分開儲存的,因為月份的天數不同,而當涉及到夏令時轉換時,一天可能只有 23 或 25 小時。使用其他單位的間隔輸入字串將被規範化為這種格式,然後以標準化的方式重構以用於輸出,例如。
SELECT '2 years 15 months 100 weeks 99 hours 123456789 milliseconds'::interval; interval --------------------------------------- 3 years 3 mons 700 days 133:17:36.789
這裡,周(被理解為“7 天”)被分開儲存,而更小和更大的時間單位被合併並規範化。
輸入欄位值可以具有小數部分,例如 '1.5 weeks'
或 '01:02:03.45'
。但是,由於 interval
在內部只儲存整數字段,小數必須轉換為更小的單位。大於月的單位的小數部分將被舍入為整數個月,例如 '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 年 2 個月 3 天 4 小時 5 分鐘 6 秒 |
傳統 Postgres 格式:1 年 2 個月 3 天 4 小時 5 分鐘 6 秒 |
P1Y2M3DT4H5M6S |
ISO 8601 “帶指示符的格式”:與上述含義相同 |
P0001-02-03T04:05:06 |
ISO 8601 “備用格式”:與上述含義相同 |
如前所述,PostgreSQL 將 interval
值儲存為月、天和微秒。對於輸出,月份欄位透過除以 12 轉換為年和月。天欄位按原樣顯示。微秒欄位被轉換為小時、分鐘、秒和秒的小數部分。因此,月、分鐘和秒將永遠不會顯示超過 0-11、0-59 和 0-59 的範圍,而顯示的年、天和小時欄位可能相當大。(如果希望將較大的天或小時值轉換為下一個更高的欄位,可以使用 justify_days
和 justify_hours
函式。)
間隔型別的輸出格式可以透過命令 SET intervalstyle
設定為四種樣式之一:sql_standard
、postgres
、postgres_verbose
或 iso_8601
。預設值為 postgres
格式。表 8.18 顯示了每種輸出樣式的示例。
如果間隔值符合標準(僅年-月或僅日-時間,無正負成分混合),則 sql_standard
樣式會產生符合 SQL 標準對間隔字面量字串的規範的輸出。否則,輸出看起來像標準的年-月字面量字串後跟一個日-時間字面量字串,並新增顯式符號以消除混合符號間隔的歧義。
當 DateStyle 引數設定為 ISO
時,postgres
樣式的輸出與 8.4 版本之前的 PostgreSQL 版本輸出匹配。
當 DateStyle
引數設定為非 ISO
輸出時,postgres_verbose
樣式的輸出與 8.4 版本之前的 PostgreSQL 版本輸出匹配。
iso_8601
樣式的輸出與 ISO 8601 標準第 4.4.3.2 節中描述的“帶指示符的格式”匹配。
表 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 |
如果您在文件中發現任何不正確的內容、與您對特定功能的體驗不符或需要進一步說明的內容,請使用 此表格 報告文件問題。