?
本文檔使用 PHP中文網(wǎng)手冊 發(fā)布
8.5. 日期/時間類型
Table 8-9顯示了PostgreSQL支持的SQL中所有日期和時間類型。 這些數(shù)據(jù)類型上可以進(jìn)行的操作在Section 9.9中描述。
Table 8-9. 日期/時間類型
| 名字 | 存儲空間 | 描述 | 最低值 | 最高值 | 分辨率 |
|---|---|---|---|---|---|
| timestamp [ (p) ] [ without time zone ] | 8字節(jié) | 日期和時間（無時區(qū)） | 4713 BC | 294276 AD | 1毫秒/14位 |
| timestamp [ (p) ] with time zone | 8字節(jié) | 日期和時間，帶時區(qū) | 4713 BC | 294276 AD | 1毫秒/14位 |
| date | 4字節(jié) | 只用于日期 | 4713 BC | 5874897 AD | 1天 |
| time [ (p) ] [ without time zone ] | 8字節(jié) | 只用于時間 | 00:00:00 | 24:00:00 | 1毫秒/14位 |
| time [ (p) ] with time zone | 12字節(jié) | 只用于一日內(nèi)時間，帶時區(qū) | 00:00:00+1459 | 24:00:00-1459 | 1毫秒/14位 |
| interval [ fields ] [ (p) ] | 12字節(jié) | 時間間隔 | -178000000年 | 178000000年 | 1毫秒/14位 |
Note: SQL標(biāo)準(zhǔn)要求僅僅將timestamp類型 等于timestamp without time zone類型，（7.3之前的版本將其看做timestamp with time zone）
time，timestamp和interval 接受一個可選的精度值p 以指明秒域中小數(shù)部分的位數(shù)。沒有明確的缺省精度， p的范圍對timestamp 和interval類型是從0到大約6。
Note: 如果timestamp數(shù)值是以雙精度浮點數(shù)(目前的缺省)的方式存儲的， 微秒的精度是可以通過全方位的價值觀。當(dāng)timestamp值存儲為雙精度浮點數(shù)（1過時的編譯時間選項），那么有效精度會小于6。 timestamp值是以2000-01-01午夜之前或之后的秒數(shù)存儲的， 而微秒的精度是為那些在2000-01-01前后幾年的日期實現(xiàn)的，對于那些遠(yuǎn)一些的日子，精度會下降。 但當(dāng)timestamp值是使用浮點實現(xiàn)數(shù)字，日期內(nèi)取得幾微秒精度。 請注意，在以浮點數(shù)存儲的時候，隨著時間間隔的增加，timestamp數(shù)值的精度會降低。 如上圖所示：從公元前4713年至5874897 AD。
相同的編譯時間選項也決定是否time和interval值存儲為 浮點數(shù)或8字節(jié)的整數(shù)。在浮點運算的情況下，大interval值降低 精密的間隔增加的大小。
對于time類型，如果使用了八字節(jié)的整數(shù)存儲， 那么p允許的范圍是從0到6， 如果使用的是浮點數(shù)存儲，那么這個范圍是0到10。
interval類型有一個額外的選項，用于通過寫這些詞組之一，限制存儲領(lǐng)域；
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標(biāo)準(zhǔn)定義的， 但是完整定義的有些方面會導(dǎo)致有問題的用法。 在大多數(shù)情況下，date，time，timestamp without time zone和timestamp with time zone的組合就應(yīng)該 能提供一切應(yīng)用需要的日期/時間的完整功能。
abstime和reltime類型是低分辨率類型， 它們被用于系統(tǒng)內(nèi)部。我們反對你使用這些類型， 因為這些舊類型的部分或全部可能會在未來的版本里消失。
8.5.1. 日期/時間輸入
日期和時間的輸入幾乎可以是任何合理的格式， 包括 ISO-8601 格式、SQL-兼容格式、傳統(tǒng)POSTGRES格式、其它的形式。 對于一些格式，日期輸入里的月和日可能會讓人迷惑， 因此系統(tǒng)支持自定義這些字段的順序。 把DateStyle參數(shù)設(shè)置為MDY就按照"月-日-年"解析， 設(shè)置為DMY就按照"日-月-年"解析，設(shè)置為YMD就按照"年-月-日"解析。
PostgreSQL在處理日期/時間輸入上 比SQL標(biāo)準(zhǔn)要求的更靈活。 參閱Appendix B獲取關(guān)于日期/時間輸入的 準(zhǔn)確分析規(guī)則和可識別文本字段，包括月份、星期幾、時區(qū)。
請記住任何日期或者時間的文本輸入需要由單引號包圍， 就像一個文本字符串一樣。參考Section 4.1.2.7 獲取更多信息。 SQL要求使用下面的語法：
type [ (p) ] 'value'
可選精度聲明中的p是一個整數(shù)， 表示在秒域中小數(shù)部分的位數(shù)，我們可以對 time,timestamp,和interval類型聲明精度。 允許的精度在上面已經(jīng)說明。如果在常量聲明中沒有聲明精度，缺省是文本值的精度。
8.5.1.1. 日期
Table 8-10顯示了date類型可能的輸入方式。
Table 8-10. 日期輸入
| 例子 | 描述 |
|---|---|
| 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. 時間
當(dāng)日時間類型是time [ (p) ] without time zone和 time [ (p) ] with time zone。 只寫time等效于time without time zone。
這些類型的有效輸入由當(dāng)日時間后面跟著可選的時區(qū)組成( 參閱Table 8-11和Table 8-12)。 如果在time without time zone類型的輸入中聲明了時區(qū)， 那么它會被悄悄地忽略。同樣指定的日期也會被忽略， 除非使用了一個包括夏令時規(guī)則的時區(qū)名，比如 America/New_York，在這種情況下， 必須指定日期以確定這個時間是標(biāo)準(zhǔn)時間還是夏令時。 時區(qū)偏移將記錄在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不影響數(shù)值 |
| 04:05 PM | 與16:05一樣；輸入小時數(shù)必須<=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 | 縮寫的時區(qū) |
| 2003-04-12 04:05:06 America/New_York | 用名字聲明的時區(qū) |
Table 8-12. 時區(qū)輸入
| 例子 | 描述 |
|---|---|
| PST | 太平洋標(biāo)準(zhǔn)時間(Pacific Standard Time) |
| America/New_York | 完整時區(qū)名稱 |
| PST8PDT | POSIX風(fēng)格的時區(qū) |
| -8:00 | ISO-8601與PST的偏移 |
| -800 | ISO-8601與PST的偏移 |
| -8 | ISO-8601與PST的偏移 |
| zulu | 軍方對UTC的縮寫 |
| z | zulu的縮寫 |
參考Section 8.5.3以獲取如何指定時區(qū)的更多信息。
8.5.1.3. 時間戳
時間戳類型的有效輸入由一個日期和時間的連接組成， 后面跟著一個可選的時區(qū)，一個可選的AD或BC。 另外，AD/BC可以出現(xiàn)在時區(qū)前面， 但這個順序并非最佳的。因此
1999-01-08 04:05:06
和：
1999-01-08 04:05:06 -8:00
都是有效的數(shù)值，它是兼容 ISO-8601的。另外， 也支持下面這種使用廣泛的格式;
January 8 04:05:06 1999 PST
被支持。
SQL標(biāo)準(zhǔn)通過"+"或者"-"是否 存在來區(qū)分timestamp without time zone和timestamp with time zone文本。因此，根據(jù)標(biāo)準(zhǔn)，
TIMESTAMP '2004-10-19 10:23:54'
是一個timestamp without time zone，而
TIMESTAMP '2004-10-19 10:23:54+02'
是一個timestamp with time zone。 PostgreSQL從來不會 在確定文本的類型之前檢查文本內(nèi)容， 因此會把上面兩個都看做是timestamp without time zone。 因此要保證把上面的第二個當(dāng)作timestamp without time zone看待， 就要給它明確的類型：
TIMESTAMP WITH TIME ZONE '2004-10-19 10:23:54+02'
如果一個文本已被確定是timestamp without time zone, PostgreSQL將悄悄忽略任何文本中指出的時區(qū)。 因此，生成的日期/時間值是從輸入值的日期/時間字段衍生出來的，并且沒有就時區(qū)進(jìn)行調(diào)整。
對于timestamp with time zone，內(nèi)部存儲的數(shù)值總是UTC(全球統(tǒng)一時間，以前也叫格林威治時間 GMT)。 如果一個輸入值有明確的時區(qū)聲明，那么它將用該時區(qū)合適的偏移量轉(zhuǎn)換成 UTC 。 如果在輸入字符串里沒有時區(qū)聲明， 那么它就假設(shè)是在系統(tǒng)的timezone參數(shù)里的那個時區(qū)，然后使用這個timezone時區(qū)轉(zhuǎn)換成UTC。
如果輸出一個timestamp with time zone，那么它總是從UTC轉(zhuǎn)換成當(dāng)前的timezone時區(qū)， 并且顯示為該時區(qū)的本地時間。要看其它時區(qū)的該時間， 要么修改timezone， 要么使用AT TIME ZONE構(gòu)造 (參閱Section 9.9.3)。
在timestamp without time zone和timestamp with time zone之間的 轉(zhuǎn)換通常假設(shè)timestamp without time zone數(shù)值應(yīng)該以timezone本地時間的形式接受或者寫出。 其它的時區(qū)引用可以用AT TIME ZONE的方式為轉(zhuǎn)換聲明。
8.5.1.4. 特殊值
PostgreSQL為方便起見支持在 Table 8-13里面顯示的幾個特殊輸入值。 值infinity 和 -infinity是特別在系統(tǒng)內(nèi)部表示的， 并且將按照同樣的方式顯示；但是其它的都只是符號縮寫， 在讀取的時候?qū)⒈晦D(zhuǎn)換成普通的日期/時間值。 特別是now和相關(guān)的字符串在讀取的時候就被轉(zhuǎn)換成對應(yīng)的數(shù)值。 所有這些值在 SQL 命令里當(dāng)作普通常量對待時，都需要寫在單引號里面。
Table 8-13. 特殊日期/時間輸入
| 輸入字符串 | 適用類型 | 描述 |
|---|---|---|
| epoch | date, timestamp | 1970-01-01 00:00:00+00 (UNIX系統(tǒng)零時) |
| infinity | date, timestamp | 比任何其它時間戳都晚 |
| -infinity | date, timestamp | 比任何其它時間戳都早 |
| now | date, time, timestamp | 當(dāng)前事務(wù)的開始時間 |
| today | date, timestamp | 今日午夜 |
| tomorrow | date, timestamp | 明日午夜 |
| yesterday | date, timestamp | 昨日午夜 |
| allballs | time | 00:00:00.00 UTC |
下列SQL兼容函數(shù)也可以用于獲取對應(yīng)數(shù)據(jù)類型的當(dāng)前時間值： CURRENT_DATE,CURRENT_TIME,CURRENT_TIMESTAMP, LOCALTIME,LOCALTIMESTAMP。 后四個接受一個可選的精度聲明(Section 9.9.4)。不過， 請注意這些SQL函數(shù)不是被當(dāng)作數(shù)據(jù)輸入字符串識別的。
8.5.2. 日期/時間輸入
日期/時間類型的輸出格式設(shè)成 ISO 8601(默認(rèn))、SQL(Ingres)、 傳統(tǒng)的POSTGRES(Unix date 格式)、German四種風(fēng)格之一。 SQL標(biāo)準(zhǔn)要求使用ISO 8601格式。"SQL"輸出格式的名字是歷史偶然。 Table 8-14顯示了每種輸出風(fēng)格的例子。 date和time類型的輸出當(dāng)然只是給出的例子里面的日期和時間部分。
Table 8-14. 日期/時間輸入
| 風(fēng)格 | 描述 | 例子 |
|---|---|---|
| ISO | ISO 8601/SQL標(biāo)準(zhǔn) | 1997-12-17 07:37:16-08 |
| SQL | 傳統(tǒng)風(fēng)格 | 12/17/1997 07:37:16.00 PST |
| POSTGRES | 原始風(fēng)格 | Wed Dec 17 07:37:16 1997 PST |
| German | 地區(qū)風(fēng)格 | 17.12.1997 07:37:16.00 PST |
如果聲明了DMY順序，那么在SQL和POSTGRES風(fēng)格里， 日期在月份之前出現(xiàn)，否則月份出現(xiàn)在日期之前(參閱Section 8.5.1看看這個設(shè)置如何影響對輸入值的解釋)。Table 8-15里有一個例子。
Table 8-15. 日期順序習(xí)慣
| datestyle設(shè)置 | 輸入順序 | 輸入樣例 |
|---|---|---|
| SQL, DMY | 日/月/年 | 17/12/1997 15:37:16.00 CET |
| SQL, MDY | 月/日/年 | 12/17/1997 07:37:16.00 PST |
| Postgres, DMY | day日/month月/year年 | Wed 17 Dec 07:37:16 1997 PST |
用戶可以用SET datestyle命令選取日期/時間的風(fēng)格，
也可以在配置文件postgresql.conf中的DateStyle參數(shù)中設(shè)置，
或者在服務(wù)器或客戶端的PGDATESTYLE環(huán)境變量中設(shè)置。
我們也可以用格式化函數(shù)to_char(參見Section 9.8)來更靈活地控制時間/日期地輸出。
8.5.3. 時區(qū)
時區(qū)和時區(qū)習(xí)慣不僅僅受地球幾何形狀的影響，還受到政治決定的影響。 到了19世紀(jì)，全球的時區(qū)變得稍微標(biāo)準(zhǔn)化了些，但是還是易于遭受隨意的修改 ，部分是因為夏時制規(guī)則。PostgreSQL使用廣泛 使用的zoneinfo時區(qū)信息數(shù)據(jù)庫有關(guān)歷史的時區(qū)規(guī)則。在未來，假設(shè) 是已知的對于一個給定的時區(qū)的最新規(guī)則會被繼續(xù)無限期的遵守。
PostgreSQL在典型應(yīng)用中盡可能與SQL的定義相兼容。 但SQL標(biāo)準(zhǔn)在日期/時間類型和功能上有一些奇怪的混淆。 兩個顯而易見的問題是：
date類型與時區(qū)沒有聯(lián)系，而time類型卻有或可以有。 然而，現(xiàn)實世界的時區(qū)只有在與時間和日期都關(guān)聯(lián)時才有意義， 因為時間偏移量(時差)可能因為實行類似夏時制這樣的制度而在一年里有所變化。
缺省的時區(qū)用一個數(shù)字常量表示與UTC的偏移(時差)。 因此，當(dāng)跨DST(夏時制)界限做日期/時間算術(shù)時， 我們根本不可能把夏時制這樣的因素計算進(jìn)去。
為了克服這些困難，我們建議在使用時區(qū)的時候，使用那些同時包含日期和時間的日期/時間類型。 我們建議不使用time with time zone類型( 盡管PostgreSQL出于合理應(yīng)用以及為了與其它RDBMS兼容的考慮支持這個類型)。 PostgreSQL假設(shè)你用于 任何類型的本地時區(qū)都只包含日期或時間(而不包含時區(qū))。
在系統(tǒng)內(nèi)部，所有日期和時間都用全球統(tǒng)一時間UTC格式存儲， 時間在發(fā)給客戶前端前由數(shù)據(jù)庫服務(wù)器根據(jù)timezone配置參數(shù)聲明的時區(qū)轉(zhuǎn)換成本地時間。
PostgreSQL允許使用三種方法指定時區(qū)：
完整的時區(qū)名，例如America/New_York。 所有可以識別的時區(qū)名在pg_timezone_names視圖中列出 (參見Section 45.60)。 PostgreSQL使用廣泛使用的zoneinfo時區(qū)數(shù)據(jù)， 所以這些時區(qū)名在其它軟件里也能被輕松的識別。
時區(qū)縮寫。例如PST。 這種縮寫名通常只是定義了相對于UTC的偏移量， 而前一種完整的時區(qū)名可能還隱含著一組夏時制轉(zhuǎn)換規(guī)則。 所有可以識別的時區(qū)縮寫在pg_timezone_abbrevs視圖中列出(參見Section 45.59)。 你不能使用時區(qū)縮寫來設(shè)置timezone或log_timezone配置參數(shù)， 但是你可以在日期/時間輸入值中結(jié)合AT TIME ZONE操作符使用時區(qū)縮寫。
除完整的時區(qū)名及其縮寫之外，PostgreSQL還接受POSIX風(fēng)格的STDoffset 或 STDoffsetDST格式的時區(qū)， 其中的STD是時區(qū)縮寫、offset是一個相對于UTC的小時偏移量、 DST是一個可選的夏時制時區(qū)縮寫(假定相對于給定的偏移量提前一小時)。 例如，如果EST5EDT不是一個已識別的時區(qū)名，那么它將等同于美國東部時間。 如果存在夏時制時區(qū)名是當(dāng)前時區(qū)名， 根據(jù)zoneinfo時區(qū)數(shù)據(jù)庫的posixrules條目中相同的夏時制事務(wù)規(guī)則，可以考慮使用這個特性。 在一個PostgreSQL標(biāo)準(zhǔn)安裝中， posixrules與US/Eastern相同，因此POSIX格式的時區(qū)聲明遵循USA夏時制規(guī)則。 如果需要，可以通過替換posixrules文件來調(diào)整該習(xí)慣。
總之，完整的時區(qū)名與時區(qū)縮寫在理論與實踐之間存在差異： 時區(qū)縮寫總是代表一個相對于UTC的固定偏移量， 然而大多數(shù)完整的時區(qū)名隱含著一個本地夏令時規(guī)則， 因此就有可能有兩個相對于UTC的不同偏移量。
需要警惕的是，由于沒有合理的時區(qū)縮寫檢查，POSIX格式的時區(qū)特點能導(dǎo)致靜默的偽輸入。 例如，使用SET TIMEZONE TO FOOBAR0時，實際上系統(tǒng)使用的是一個很特別的UTC縮寫。 另一個需要注意的是，在POSIX時區(qū)名中，積極的偏移用于west格林尼治位置。 在其他地方，PostgreSQL遵循ISO-8601規(guī)定，即積極的時區(qū)偏移east格林威治。
總體而言，PostgreSQL8.2版本以后時區(qū)名在所有情況下 都是大小寫無關(guān)的。而之前的版本在某些情況下是大小寫敏感的。
無論是完整的時區(qū)名還是時區(qū)縮寫都不是硬連接進(jìn)服務(wù)器的， 它們都是從安裝目錄下的.../share/timezone/和.../share/timezonesets/配置文件中獲取的(參見Section B.3)
可以在postgresql.conf文件里設(shè)置timezone配置參數(shù)， 或者用任何其它在Chapter 18描述的標(biāo)準(zhǔn)方法。除此之外， 還有好幾種特殊方法可以設(shè)置它：
如果既沒有在postgresql.conf里也沒有在命令行開關(guān) 上聲明timezone，那么服務(wù)器將試圖使用服務(wù)器主機(jī)上的TZ環(huán)境變量 作為服務(wù)器的缺省時區(qū)。 如果TZ沒有定義或者是PostgreSQL不認(rèn)識的時區(qū)名， 那么服務(wù)器將試圖通過檢查C庫函數(shù)localtime()的行為來判斷操作系統(tǒng)的缺省時區(qū)。 缺省時區(qū)是按照最接近PostgreSQL的已知時區(qū)的原則來選擇的。 （如果沒有指定，這些規(guī)則也可以用來選擇默認(rèn)值log_timezone）。
使用SQL命令SET TIME ZONE為會話設(shè)置時區(qū)， 這是SET TIMEZONE TO的一個可選的拼寫方式， 更加兼容標(biāo)準(zhǔn)。
如果在客戶端設(shè)置了PGTZ環(huán)境變量， 那么libpq在連接時將使用 這個環(huán)境變量給后端發(fā)送一個SET TIME ZONE命令。
8.5.4. 間隔輸入
interval類型值可以用下面的詳細(xì)語法寫：
[@] quantity unit [quantity unit...] [direction]
這里quantity是一個數(shù)字（可能已標(biāo)記）； unit可以是microsecond，millisecond，second， minute，hour，day，week， month，year，decade，century，millennium或這些單位的縮寫或復(fù)數(shù)。 direction可以是ago或為空。@標(biāo)記是可選的。ago否定所有。 如果IntervalStyle設(shè)置為postgres_verbose，那么這個語法同樣用于間隔輸入。
可以在沒有明確單位標(biāo)記的情況下聲明天，小時，分鐘和秒。 例如，'1 12:59:10'等同于'1 day 12 hours 59 min 10 sec'。 同樣，可以用一個破折號來聲明一個年和月的組合，例如'200-10'等同于'200 years 10 months'。 （事實上，SQL標(biāo)準(zhǔn)值允許短的格式，并且當(dāng) IntervalStyle設(shè)置為sql_standard時，用于輸出）。
要么使用ISO 8601標(biāo)準(zhǔn)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有說明。 可以忽略單位，也可以以任意順序聲明，但單位小于一天時必須在T之后。 尤其M的含義依賴于它在T之前或之后。
Table 8-16. ISO8601間隔單位的縮寫
| 縮寫 | 含義 |
|---|---|
| Y | 年 |
| M | 月（日期部分） |
| W | 周 |
| D | 日 |
| H | 小時 |
| M | 分鐘（時間部分） |
| S | 秒 |
以縮寫格式：
P [ years-months-days ] [ T hours:minutes:seconds ]
一個字符串必須以P開始，然后以T隔開日期和時間。 給出的值是如同ISO 8601日期的數(shù)字。
當(dāng)用fields規(guī)范寫一個時間間隔常熟，或?qū)⒁粋€字符串標(biāo)記為用fields規(guī)范定義的一個間隔柱時， 未標(biāo)記單位的解釋由fields解釋。如INTERVAL '1' YEAR讀作1年，然而INTERVAL '1'代表1秒。 同樣，fields規(guī)范中最低有效字段值規(guī)定會被靜默的忽略。如，INTERVAL '1 day 2:03:04' HOUR TO MINUTE會導(dǎo)致刪除 秒字段，而不是天字段。
根據(jù)SQL標(biāo)準(zhǔn)，間隔值的所有字段必須有相同的符號，因此前導(dǎo)負(fù)號可以用于所有字段； 如'-1 2:03:04'中負(fù)號同時應(yīng)用于天和小時/分鐘/秒。 PostgreSQL允許字段有不同的標(biāo)記，并且傳統(tǒng)上，文本表述中的每個字段會被認(rèn)為是獨立標(biāo)記的， 因此在這個例子中的小時/分鐘/秒被認(rèn)為是允許的。如果IntervalStyle被設(shè)置為sql_standard，那么前導(dǎo)標(biāo)記被認(rèn)為是應(yīng)用于所有字段的 （當(dāng)然前提是沒有再出現(xiàn)其他標(biāo)記），否則會使用傳統(tǒng)的PostgreSQL解釋。為了避免這種奇異，建議為每個字段附上一個明確的標(biāo)記。
PostgreSQL內(nèi)部，interval值被存儲為月，日，秒的格式，這是因為月中包含天，并且如果進(jìn)行了夏令時調(diào)整，那么一天可以有23或25小時。
當(dāng)秒字段可以存儲分?jǐn)?shù)時，月和天字段可以是整數(shù)型。由于時間間隔通常是由常量字符串或timestamp減法來定義的，
這種存儲方法在大多數(shù)情況下很有效。justify_days和justify_hours函數(shù)可用于調(diào)整溢出正常范圍值的天和小時。
在詳細(xì)的輸出格式，以及更緊湊的輸入格式中，字段值可以有小數(shù)部分，例如'1.5 week'或'01:02:03.45'。 這種輸入被轉(zhuǎn)換成恰當(dāng)?shù)脑?，天和秒來存儲。由于這樣會產(chǎn)生小數(shù)的月或天，因此在低階字段中引入了分?jǐn)?shù)，用以1 month = 30 days 和 1 day = 24 hours的轉(zhuǎn)換。 例如，'1.5 month'即1個月15天。輸出中，只有秒可以寫成分?jǐn)?shù)形式。
Table 8-17中有一些有效的interval輸入的例子。
Table 8-17. 間隔輸入
| 示例 | 說明 |
|---|---|
| 1-2 | SQL標(biāo)準(zhǔn)格式：一年兩個月 |
| 3 4:05:06 | SQL標(biāo)準(zhǔn)格式：3天4小時5分6秒 |
| 1 year 2 months 3 days 4 hours 5 minutes 6 seconds | 傳統(tǒng)Postgres格式: 1年2個月3天4小時5分鐘6秒 |
| P1Y2M3DT4H5M6S | ISO 8601 "帶標(biāo)識符格式":與上面相同含義 |
| P0001-02-03T04:05:06 | ISO 8601 "縮寫格式":與上面相同含義 |
8.5.5. 間隔輸出
間隔類型的輸出格式可以用命令SET intervalstyle設(shè)置為下面四種類型：sql_standard，postgres，postgres_verbose或iso_8601 默認(rèn)是postgres格式，Table 8-18中有每種格式的示例。
sql_standard格式產(chǎn)生的輸出結(jié)果符合SQL的區(qū)間字符串標(biāo)準(zhǔn)， 如果間隔值滿足標(biāo)準(zhǔn)的限制（無論年-月，或只有天-時間，沒有積極和消極的構(gòu)成的混合）。 否則類似一個標(biāo)準(zhǔn)年-月文本字符串后跟有一個天-時間文本字符串的輸出，帶有添加明確標(biāo)記的消除歧義混合信號的時間間隔。
postgres格式的輸出與PostgreSQL8.4（此時DateStyle參數(shù)設(shè)置為ISO）之前的輸出是一致的。
postgres格式的輸出與PostgreSQL8.4（此時DateStyle參數(shù)設(shè)置為非ISO輸出）之前的輸出是一致的
iso_8601格式的輸出與ISO 8601標(biāo)準(zhǔn)4.4.3.2節(jié)中的"format with designators"一致。
Table 8-18. 間隔輸出格式示例
| 格式 | 年-月區(qū)間 | 天-時間區(qū)間 | 混合區(qū)間 |
|---|---|---|---|
| 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 |
8.5.6. 內(nèi)部
PostgreSQL 使用儒略歷法計算所有日期/時間， 假設(shè)一年的長度是365.2425天。這個方法可以很精確地預(yù)計/計算從公元前4713年到很久的未來的任意一天的日期。
19世紀(jì)以前的日期傳統(tǒng)(歷法)只是對一些趣味讀物有意義， 而在我們這里好像沒有充分的理由把它們編碼入日期/時間控制器里面去。