8.5. 日期/时间类型

Table 8-9显示了PostgreSQL支持的SQL中所有日期和时间类型。 这些数据类型上可以进行的操作在Section 9.9中描述。

Table 8-9. 日期/时间类型

名字存储空间描述最低值最高值分辨率
timestamp [ (p) ] [ without time zone ]8字节日期和时间(无时区)4713 BC294276 AD1毫秒/14位
timestamp [ (p) ] with time zone8字节日期和时间,带时区4713 BC294276 AD1毫秒/14位
date4字节只用于日期4713 BC5874897 AD1天
time [ (p) ] [ without time zone ]8字节只用于时间00:00:0024:00:001毫秒/14位
time [ (p) ] with time zone12字节只用于一日内时间,带时区00:00:00+145924:00:00-14591毫秒/14位
interval [ fields ] [ (p) ]12字节时间间隔-178000000年178000000年1毫秒/14位

Note: SQL标准要求仅仅将timestamp类型 等于timestamp without time zone类型,(7.3之前的版本将其看做timestamp with time zone

timetimestampinterval 接受一个可选的精度值p 以指明秒域中小数部分的位数。没有明确的缺省精度, p的范围对timestampinterval类型是从0到大约6。

Note: 如果timestamp数值是以双精度浮点数(目前的缺省)的方式存储的, 微秒的精度是可以通过全方位的价值观。当timestamp值存储为双精度浮点数(1过时的编译时间选项),那么有效精度会小于6。 timestamp值是以2000-01-01午夜之前或之后的秒数存储的, 而微秒的精度是为那些在2000-01-01前后几年的日期实现的,对于那些远一些的日子,精度会下降。 但当timestamp值是使用浮点实现数字,日期内取得几微秒精度。 请注意,在以浮点数存储的时候,随着时间间隔的增加,timestamp数值的精度会降低。 如上图所示:从公元前4713年至5874897 AD。

相同的编译时间选项也决定是否timeinterval值存储为 浮点数或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

需要注意的是,如果同时声明了fieldspfields必须包括SECOND,因为精度只适用于秒。

time with time zone类型是SQL标准定义的, 但是完整定义的有些方面会导致有问题的用法。 在大多数情况下,datetimetimestamp without time zonetimestamp with time zone的组合就应该 能提供一切应用需要的日期/时间的完整功能。

abstimereltime类型是低分辨率类型, 它们被用于系统内部。我们反对你使用这些类型, 因为这些旧类型的部分或全部可能会在未来的版本里消失。

8.5.1. 日期/时间输入

日期和时间的输入几乎可以是任何合理的格式, 包括 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类型声明精度。 允许的精度在上面已经说明。如果在常量声明中没有声明精度,缺省是文本值的精度。

8.5.1.1. 日期

Table 8-10显示了date类型可能的输入方式。

Table 8-10. 日期输入

例子描述
1999-01-08ISO 8601格式(建议格式),任何方式下都是1999年1月8号
January 8, 1999在任何datestyle输入模式下都无歧义
1/8/1999在MDY下是一月八号;在DMY模式下是八月一日
1/18/1999MDY 模式下是一月十八日,其它模式下被拒绝
01/02/03MDY模式下的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-08YMD模式下是1月8日,否则错误
08-Jan-99一月八日,除了在YMD模式下是错误的之外
Jan-08-99一月八日,除了在YMD模式下是错误的之外
19990108ISO 8601;任何模式下都是1999年1月8日
990108ISO 8601;任何模式下都是1999年1月8日
1999.008年和年里的第几天
J2451187儒略日
January 8, 99 BC公元前99年

8.5.1.2. 时间

当日时间类型是time [ (p) ] without time zonetime [ (p) ] with time zone。 只写time等效于time without time zone

这些类型的有效输入由当日时间后面跟着可选的时区组成( 参阅Table 8-11Table 8-12)。 如果在time without time zone类型的输入中声明了时区, 那么它会被悄悄地忽略。同样指定的日期也会被忽略, 除非使用了一个包括夏令时规则的时区名,比如 America/New_York,在这种情况下, 必须指定日期以确定这个时间是标准时间还是夏令时。 时区偏移将记录在time with time zone中。

Table 8-11. 时间输入

例子描述
04:05:06.789ISO 8601
04:05:06ISO 8601
04:05ISO 8601
040506ISO 8601
04:05 AM与04:05一样;AM不影响数值
04:05 PM与16:05一样;输入小时数必须<=12
04:05:06.789-8ISO 8601
04:05:06-08:00ISO 8601
04:05-08:00ISO 8601
040506-08ISO 8601
04:05:06 PST缩写的时区
2003-04-12 04:05:06 America/New_York用名字声明的时区

Table 8-12. 时区输入

例子描述
PST太平洋标准时间(Pacific Standard Time)
America/New_York完整时区名称
PST8PDTPOSIX风格的时区
-8:00ISO-8601与PST的偏移
-800ISO-8601与PST的偏移
-8ISO-8601与PST的偏移
zulu军方对UTC的缩写
zzulu的缩写

参考Section 8.5.3以获取如何指定时区的更多信息。

8.5.1.3. 时间戳

时间戳类型的有效输入由一个日期和时间的连接组成, 后面跟着一个可选的时区,一个可选的ADBC。 另外,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 zonetimestamp 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 zonePostgreSQL从来不会 在确定文本的类型之前检查文本内容, 因此会把上面两个都看做是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 zonetimestamp with time zone之间的 转换通常假设timestamp without time zone数值应该以timezone本地时间的形式接受或者写出。 其它的时区引用可以用AT TIME ZONE的方式为转换声明。

8.5.1.4. 特殊值

PostgreSQL为方便起见支持在 Table 8-13里面显示的几个特殊输入值。 值infinity-infinity是特别在系统内部表示的, 并且将按照同样的方式显示;但是其它的都只是符号缩写, 在读取的时候将被转换成普通的日期/时间值。 特别是now和相关的字符串在读取的时候就被转换成对应的数值。 所有这些值在 SQL 命令里当作普通常量对待时,都需要写在单引号里面。

Table 8-13. 特殊日期/时间输入

输入字符串适用类型描述
epochdate, timestamp1970-01-01 00:00:00+00 (UNIX系统零时)
infinitydate, timestamp比任何其它时间戳都晚
-infinitydate, timestamp比任何其它时间戳都早
nowdate, time, timestamp当前事务的开始时间
todaydate, timestamp今日午夜
tomorrowdate, timestamp明日午夜
yesterdaydate, timestamp昨日午夜
allballstime00:00:00.00 UTC

下列SQL兼容函数也可以用于获取对应数据类型的当前时间值: CURRENT_DATE,CURRENT_TIME,CURRENT_TIMESTAMP, LOCALTIME,LOCALTIMESTAMP。 后四个接受一个可选的精度声明(Section 9.9.4)。不过, 请注意这些SQL函数不是被当作数据输入字符串识别的。

8.5.2. 日期/时间输入

日期/时间类型的输出格式设成 ISO 8601(默认)、SQL(Ingres)、 传统的POSTGRES(Unix date 格式)、German四种风格之一。 SQL标准要求使用ISO 8601格式。"SQL"输出格式的名字是历史偶然。 Table 8-14显示了每种输出风格的例子。 datetime类型的输出当然只是给出的例子里面的日期和时间部分。

Table 8-14. 日期/时间输入

风格描述例子
ISOISO 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, DMYday日/month月/year年Wed 17 Dec 07:37:16 1997 PST

用户可以用SET datestyle命令选取日期/时间的风格, 也可以在配置文件postgresql.conf中的DateStyle参数中设置, 或者在服务器或客户端的PGDATESTYLE环境变量中设置。 我们也可以用格式化函数to_char(参见Section 9.8)来更灵活地控制时间/日期地输出。

8.5.3. 时区

时区和时区习惯不仅仅受地球几何形状的影响,还受到政治决定的影响。 到了19世纪,全球的时区变得稍微标准化了些,但是还是易于遭受随意的修改 ,部分是因为夏时制规则。PostgreSQL使用广泛 使用的zoneinfo时区信息数据库有关历史的时区规则。在未来,假设 是已知的对于一个给定的时区的最新规则会被继续无限期的遵守。

PostgreSQL在典型应用中尽可能与SQL的定义相兼容。 但SQL标准在日期/时间类型和功能上有一些奇怪的混淆。 两个显而易见的问题是:

为了克服这些困难,我们建议在使用时区的时候,使用那些同时包含日期和时间的日期/时间类型。 我们建议使用time with time zone类型( 尽管PostgreSQL出于合理应用以及为了与其它RDBMS兼容的考虑支持这个类型)。 PostgreSQL假设你用于 任何类型的本地时区都只包含日期或时间(而不包含时区)。

在系统内部,所有日期和时间都用全球统一时间UTC格式存储, 时间在发给客户前端前由数据库服务器根据timezone配置参数声明的时区转换成本地时间。

PostgreSQL允许使用三种方法指定时区:

总之,完整的时区名与时区缩写在理论与实践之间存在差异: 时区缩写总是代表一个相对于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描述的标准方法。除此之外, 还有好几种特殊方法可以设置它:

8.5.4. 间隔输入

interval类型值可以用下面的详细语法写:

[@] quantity unit [quantity unit...] [direction]

这里quantity是一个数字(可能已标记); unit可以是microsecondmillisecondsecondminutehourdayweekmonthyeardecadecenturymillennium或这些单位的缩写或复数。 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之前或之后。

Table 8-16. ISO8601间隔单位的缩写

缩写含义
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_daysjustify_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输入的例子。

Table 8-17. 间隔输入

示例说明
1-2SQL标准格式:一年两个月
3 4:05:06SQL标准格式:3天4小时5分6秒
1 year 2 months 3 days 4 hours 5 minutes 6 seconds传统Postgres格式: 1年2个月3天4小时5分钟6秒
P1Y2M3DT4H5M6SISO 8601 "带标识符格式":与上面相同含义
P0001-02-03T04:05:06ISO 8601 "缩写格式":与上面相同含义

8.5.5. 间隔输出

间隔类型的输出格式可以用命令SET intervalstyle设置为下面四种类型:sql_standardpostgrespostgres_verboseiso_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"一致。

Table 8-18. 间隔输出格式示例

格式年-月区间天-时间区间混合区间
sql_standard1-23 4:05:06-1-2 +3 -4:05:06
postgres1年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_8601P1Y2MP3DT4H5M6SP-1Y-2M3DT-4H-5M-6S

8.5.6. 内部

PostgreSQL 使用儒略历法计算所有日期/时间, 假设一年的长度是365.2425天。这个方法可以很精确地预计/计算从公元前4713年到很久的未来的任意一天的日期。

19世纪以前的日期传统(历法)只是对一些趣味读物有意义, 而在我们这里好像没有充分的理由把它们编码入日期/时间控制器里面去。