| PostgreSQL 9.0.4 中文文档 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 8. 数据类型 | Fast Forward | Next |
Table 8-9显示了PostgreSQL支持的SQL中所有日期和时间类型。 这些数据类型上可以进行的操作在Section 9.9中描述。
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类型，（7.3之前的版本将其看做timestamp with time zone）
time，timestamp和interval 接受一个可选的精度值p 以指明秒域中小数部分的位数。没有明确的缺省精度， p的范围对timestamp 和interval类型是从0到大约6。
Note: 如果timestamp数值是以双精度浮点数(目前的缺省)的方式存储的， 微秒的精度是可以通过全方位的价值观。当timestamp值存储为双精度浮点数（1过时的编译时间选项），那么有效精度会小于6。 timestamp值是以2000-01-01午夜之前或之后的秒数存储的， 而微秒的精度是为那些在2000-01-01前后几年的日期实现的，对于那些远一些的日子，精度会下降。 但当timestamp值是使用浮点实现数字，日期内取得几微秒精度。 请注意，在以浮点数存储的时候，随着时间间隔的增加，timestamp数值的精度会降低。 如上图所示：从公元前4713年至5874897 AD。
相同的编译时间选项也决定是否time和interval值存储为 浮点数或8字节的整数。在浮点运算的情况下，大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类型是低分辨率类型， 它们被用于系统内部。我们反对你使用这些类型， 因为这些旧类型的部分或全部可能会在未来的版本里消失。
日期和时间的输入几乎可以是任何合理的格式， 包括 ISO-8601 格式、SQL-兼容格式、传统POSTGRES格式、其它的形式。 对于一些格式，日期输入里的月和日可能会让人迷惑， 因此系统支持自定义这些字段的顺序。 把DateStyle参数设置为MDY就按照"月-日-年"解析， 设置为DMY就按照"日-月-年"解析，设置为YMD就按照"年-月-日"解析。
PostgreSQL在处理日期/时间输入上 比SQL标准要求的更灵活。 参阅Appendix B获取关于日期/时间输入的 准确分析规则和可识别文本字段，包括月份、星期几、时区。
请记住任何日期或者时间的文本输入需要由单引号包围， 就像一个文本字符串一样。参考Section 4.1.2.7 获取更多信息。 SQL要求使用下面的语法：
type [ (p) ] 'value'
可选精度声明中的p是一个整数， 表示在秒域中小数部分的位数，我们可以对 time,timestamp,和interval类型声明精度。 允许的精度在上面已经说明。如果在常量声明中没有声明精度，缺省是文本值的精度。
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年 |
当日时间类型是time [ (p) ] without time zone和 time [ (p) ] with time zone。 只写time等效于time without time zone。
这些类型的有效输入由当日时间后面跟着可选的时区组成( 参阅Table 8-11和Table 8-12)。 如果在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以获取如何指定时区的更多信息。
时间戳类型的有效输入由一个日期和时间的连接组成， 后面跟着一个可选的时区，一个可选的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 without 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参数里的那个时区，然后使用这个timezone时区转换成UTC。
如果输出一个timestamp with time zone，那么它总是从UTC转换成当前的timezone时区， 并且显示为该时区的本地时间。要看其它时区的该时间， 要么修改timezone， 要么使用AT TIME ZONE构造 (参阅Section 9.9.3)。
在timestamp without time zone和timestamp with time zone之间的 转换通常假设timestamp without time zone数值应该以timezone本地时间的形式接受或者写出。 其它的时区引用可以用AT TIME ZONE的方式为转换声明。
PostgreSQL为方便起见支持在 Table 8-13里面显示的几个特殊输入值。 值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)。不过， 请注意这些SQL函数不是被当作数据输入字符串识别的。
日期/时间类型的输出格式设成 ISO 8601(默认)、SQL(Ingres)、 传统的POSTGRES(Unix date 格式)、German四种风格之一。 SQL标准要求使用ISO 8601格式。"SQL"输出格式的名字是历史偶然。 Table 8-14显示了每种输出风格的例子。 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 |
如果声明了DMY顺序，那么在SQL和POSTGRES风格里， 日期在月份之前出现，否则月份出现在日期之前(参阅Section 8.5.1看看这个设置如何影响对输入值的解释)。Table 8-15里有一个例子。
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 | day日/month月/year年 | Wed 17 Dec 07:37:16 1997 PST |
用户可以用SET datestyle命令选取日期/时间的风格，
也可以在配置文件postgresql.conf中的DateStyle参数中设置，
或者在服务器或客户端的PGDATESTYLE环境变量中设置。
我们也可以用格式化函数to_char(参见Section 9.8)来更灵活地控制时间/日期地输出。
时区和时区习惯不仅仅受地球几何形状的影响，还受到政治决定的影响。 到了19世纪，全球的时区变得稍微标准化了些，但是还是易于遭受随意的修改 ，部分是因为夏时制规则。PostgreSQL使用广泛 使用的zoneinfo时区信息数据库有关历史的时区规则。在未来，假设 是已知的对于一个给定的时区的最新规则会被继续无限期的遵守。
PostgreSQL在典型应用中尽可能与SQL的定义相兼容。 但SQL标准在日期/时间类型和功能上有一些奇怪的混淆。 两个显而易见的问题是：
date类型与时区没有联系，而time类型却有或可以有。 然而，现实世界的时区只有在与时间和日期都关联时才有意义， 因为时间偏移量(时差)可能因为实行类似夏时制这样的制度而在一年里有所变化。
缺省的时区用一个数字常量表示与UTC的偏移(时差)。 因此，当跨DST(夏时制)界限做日期/时间算术时， 我们根本不可能把夏时制这样的因素计算进去。
为了克服这些困难，我们建议在使用时区的时候，使用那些同时包含日期和时间的日期/时间类型。 我们建议不使用time with time zone类型( 尽管PostgreSQL出于合理应用以及为了与其它RDBMS兼容的考虑支持这个类型)。 PostgreSQL假设你用于 任何类型的本地时区都只包含日期或时间(而不包含时区)。
在系统内部，所有日期和时间都用全球统一时间UTC格式存储， 时间在发给客户前端前由数据库服务器根据timezone配置参数声明的时区转换成本地时间。
PostgreSQL允许使用三种方法指定时区：
完整的时区名，例如America/New_York。 所有可以识别的时区名在pg_timezone_names视图中列出 (参见Section 45.60)。 PostgreSQL使用广泛使用的zoneinfo时区数据， 所以这些时区名在其它软件里也能被轻松的识别。
时区缩写。例如PST。 这种缩写名通常只是定义了相对于UTC的偏移量， 而前一种完整的时区名可能还隐含着一组夏时制转换规则。 所有可以识别的时区缩写在pg_timezone_abbrevs视图中列出(参见Section 45.59)。 你不能使用时区缩写来设置timezone或log_timezone配置参数， 但是你可以在日期/时间输入值中结合AT TIME ZONE操作符使用时区缩写。
除完整的时区名及其缩写之外，PostgreSQL还接受POSIX风格的STDoffset 或 STDoffsetDST格式的时区， 其中的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格林威治。
总体而言，PostgreSQL8.2版本以后时区名在所有情况下 都是大小写无关的。而之前的版本在某些情况下是大小写敏感的。
无论是完整的时区名还是时区缩写都不是硬连接进服务器的， 它们都是从安装目录下的.../share/timezone/和.../share/timezonesets/配置文件中获取的(参见Section B.3)
可以在postgresql.conf文件里设置timezone配置参数， 或者用任何其它在Chapter 18描述的标准方法。除此之外， 还有好几种特殊方法可以设置它：
如果既没有在postgresql.conf里也没有在命令行开关 上声明timezone，那么服务器将试图使用服务器主机上的TZ环境变量 作为服务器的缺省时区。 如果TZ没有定义或者是PostgreSQL不认识的时区名， 那么服务器将试图通过检查C库函数localtime()的行为来判断操作系统的缺省时区。 缺省时区是按照最接近PostgreSQL的已知时区的原则来选择的。 （如果没有指定，这些规则也可以用来选择默认值log_timezone）。
使用SQL命令SET TIME ZONE为会话设置时区， 这是SET TIMEZONE TO的一个可选的拼写方式， 更加兼容标准。
如果在客户端设置了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或为空。@标记是可选的。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的"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之前或之后。
以缩写格式：
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中有一些有效的interval输入的例子。
间隔类型的输出格式可以用命令SET intervalstyle设置为下面四种类型：sql_standard，postgres，postgres_verbose或iso_8601 默认是postgres格式，Table 8-18中有每种格式的示例。
sql_standard格式产生的输出结果符合SQL的区间字符串标准， 如果间隔值满足标准的限制（无论年-月，或只有天-时间，没有积极和消极的构成的混合）。 否则类似一个标准年-月文本字符串后跟有一个天-时间文本字符串的输出，带有添加明确标记的消除歧义混合信号的时间间隔。
postgres格式的输出与PostgreSQL8.4（此时DateStyle参数设置为ISO）之前的输出是一致的。
postgres格式的输出与PostgreSQL8.4（此时DateStyle参数设置为非ISO输出）之前的输出是一致的
iso_8601格式的输出与ISO 8601标准4.4.3.2节中的"format with designators"一致。
PostgreSQL 使用儒略历法计算所有日期/时间， 假设一年的长度是365.2425天。这个方法可以很精确地预计/计算从公元前4713年到很久的未来的任意一天的日期。
19世纪以前的日期传统(历法)只是对一些趣味读物有意义， 而在我们这里好像没有充分的理由把它们编码入日期/时间控制器里面去。