8.5.3. Time Zones

8.5.3. Time Zones

8.5.3.时区

Time zones, and time-zone conventions, are influenced by political decisions, not just earth geometry. Time zones around the world became somewhat standardized during the 1900s, but continue to be prone to arbitrary changes, particularly with respect to daylight-savings rules. PostgreSQL uses the widely-used IANA (Olson) time zone database for information about historical time zone rules. For times in the future, the assumption is that the latest known rules for a given time zone will continue to be observed indefinitely far into the future.

时区和时区约定受政治决策的影响，而不仅限于地球的几何形状。1900年代，世界各地的时区变得有些标准化，但仍然容易发生任意变化，特别是在夏令时方面。 PostgreSQL使用广泛使用的IANA（Olson）时区数据库来获取有关历史时区规则的信息。对于将来的时间，假设是在给定时区的最新已知规则将继续无限远地遵守到将来。

 

PostgreSQL endeavors to be compatible with the SQL standard definitions for typical usage. However,the SQL standard has an odd mix of date and time types and capabilities. Two obvious problems are:

PostgreSQL努力与SQL标准定义的典型用法兼容。但是，SQL标准将日期和时间类型与功能混合在一起。两个明显的问题是：

 

• Although the date type cannot have an associated time zone, the time type can. Time zones in the real world have little meaning unless associated with a date as well as a time, since the offset can vary through the year with daylight-saving time boundaries.

•尽管日期类型不能具有关联的时区，但是时间类型可以。 除非与日期和时间相关联，否则现实世界中的时区几乎没有意义，因为偏移量会随着夏时制的时限在一年中变化。

 

• The default time zone is specified as a constant numeric offset from UTC. It is therefore impossible to adapt to daylight-saving time when doing date/time arithmetic across DST boundaries. 

•默认时区指定为距UTC恒定的数值偏移量。因此，在DST边界上进行日期/时间运算时，无法适应夏令时。

 

To address these difficulties, we recommend using date/time types that contain both date and time when using time zones. We do not recommend using the type time with time zone (though it is supported by PostgreSQL for legacy applications and for compliance with the SQL standard).PostgreSQL assumes your local time zone for any type containing only date or time.

为解决这些困难，建议您在使用时区时使用同时包含日期和时间的日期/时间类型。我们不建议您使用time with time zone类型（尽管PostgreSQL支持旧版应用程序并符合SQL标准）。PostgreSQL假定您的本地时区为仅包含日期或时间的任何类型。

 

All timezone-aware dates and times are stored internally in UTC. They are converted to local time in the zone specified by the TimeZone configuration parameter before being displayed to the client.PostgreSQL allows you to specify time zones in three different forms:

所有可识别时区的日期和时间都在内部存储为UTC。在将它们显示给客户端之前，会将它们转换为TimeZone配置参数指定的时区中的本地时间。PostgreSQL允许您以三种不同的形式指定时区：

 

• A full time zone name, for example America/New_York. The recognized time zone names are listed in the pg_timezone_names view (see Section 52.90). PostgreSQL uses the widely-used IANA time zone data for this purpose, so the same time zone names are also recognized by other software.

•全时区名称，例如America/New_York。可识别的时区名称在pg_timezone_names视图中列出（请参见第52.90节）。PostgreSQL为此目的使用了广泛使用的IANA时区数据，因此其他软件也可以识别相同的时区名称。

 

• A time zone abbreviation, for example PST. Such a specification merely defines a particular offset from UTC, in contrast to full time zone names which can imply a set of daylight savings transition-date rules as well. The recognized abbreviations are listed in the pg_timezone_abbrevs view (see Section 52.89). You cannot set the configuration parameters TimeZone or log_timezone to a time zone abbreviation, but you can use abbreviations in date/time input values and with the AT TIME ZONE operator.

•时区缩写，例如PST。与全时区名称相反，这样的规范仅定义了与UTC的特定偏移量，而全时区名称也可能暗示一组夏时制过渡日期规则。公认的缩写在pg_timezone_abbrevs视图中列出（请参见第52.89节）。您不能将配置参数TimeZone或log_timezone设置为时区缩写，但是可以在日期/时间输入值中使用缩写，并与AT TIME ZONE运算符一起使用。

 

• In addition to the timezone names and abbreviations, PostgreSQL will accept POSIX-style time zone specifications of the form STDoffset or STDoffsetDST, where STD is a zone abbreviation, offset is a numeric offset in hours west from UTC, and DST is an optional daylight-savings zone abbreviation, assumed to stand for one hour ahead of the given offset. For example, if EST5EDT were not already a recognized zone name, it would be accepted and would be functionally equivalent to United States East Coast time. In this syntax, a zone abbreviation can be a string of letters, or an arbitrary string surrounded by angle brackets (<>). When a daylight-savings zone abbreviation is present, it is assumed to be used according to the same daylight-savings transition rules used in the IANA time zone database's posixrules entry. In a standard PostgreSQL installation,posixrules is the same as US/Eastern, so that POSIX-style time zone specifications follow USA daylight-savings rules. If needed, you can adjust this behavior by replacing the posixrules file.

•除时区名称和缩写外，PostgreSQL还将接受POSIX风格的时区规范，格式为STDoffset或STDoffsetDST，其中STD是时区缩写，offset是距UTC以小时为单位的数字偏移，DST是可选的夏令时-节约区的缩写，假定比给定偏移量早一小时。例如，如果EST5EDT尚不是公认的区域名称，它将被接受并且在功能上等同于美国东海岸时间。在此语法中，区域缩写可以是字母字符串，也可以是尖括号（<>）包围的任意字符串。如果存在夏令时缩写，则假定它是根据IANA时区数据库的posixrules条目中使用的相同的夏令时转换规则来使用的。在标准PostgreSQL安装中，posixrules与美国/东部相同，因此POSIX风格的时区规范遵循美国夏令时规则。如果需要，可以通过替换posixrules文件来调整此行为。

 

In short, this is the difference between abbreviations and full names: abbreviations represent a specific offset from UTC, whereas many of the full names imply a local daylight-savings time rule, and so have two possible UTC offsets. As an example, 2014-06-04 12:00 America/New_York represents noon local time in New York, which for this particular date was Eastern Daylight Time (UTC-4). So 2014-06-04 12:00 EDT specifies that same time instant. But 2014-06-04 12:00 EST specifies noon Eastern Standard Time (UTC-5), regardless of whether daylight savings was nominally in effect on that date.

简而言之，这是缩写和全名之间的区别：缩写表示与UTC的特定偏移量，而许多全名暗示着当地的夏时制规则，因此有两个可能的UTC偏移量。例如，2014-06-04 12:00 America / New_York代表纽约当地时间中午，这个特定日期是美国东部夏令时间（UTC-4）。因此，2014年6月4日12:00 EDT指定了同一时刻。但2014年6月4日12:00 EST会指定东部标准时间（UTC-5）中午，无论该日期的夏令时名义上是否生效。

 

To complicate matters, some jurisdictions have used the same timezone abbreviation to mean different UTC offsets at different times; for example, in Moscow MSK has meant UTC+3 in some years and UTC+4 in others. PostgreSQL interprets such abbreviations according to whatever they meant (or had  most recently meant) on the specified date; but, as with the EST example above, this is not necessarily the same as local civil time on that date.

使事情复杂化的是，某些管辖区使用了相同的时区缩写来表示不同时间的不同UTC偏移量； 例如，在莫斯科，MSK在某些年份中表示UTC + 3，在另一些年份中表示UTC + 4。 PostgreSQL根据指定日期的含义（或最近的含义）解释这些缩写。 但是，与上面的EST示例一样，该时间不必与该日期的当地民事时间相同。

 

One should be wary that the POSIX-style time zone feature can lead to silently accepting bogus input,since there is no check on the reasonableness of the zone abbreviations. For example, SET TIMEZONE TO FOOBAR0 will work, leaving the system effectively using a rather peculiar abbreviation for UTC. Another issue to keep in mind is that in POSIX time zone names, positive offsets are used for locations west of Greenwich. Everywhere else, PostgreSQL follows the ISO-8601 convention that positive timezone offsets are east of Greenwich.

应当警惕的是，由于没有检查时区缩写的合理性，因此POSIX样式的时区功能可能会导致接受伪造的输入而没有提示。例如，SET TIMEZONE TO FOOBAR0将起作用，而使得系统使用了UTC的一个特有缩写。要记住的另一个问题是，在POSIX时区名称中，正偏移量用于格林威治以西的位置。PostgreSQL在其他任何地方都遵循ISO-8601约定，正时区偏移量位于格林威治以东。

 

In all cases, timezone names and abbreviations are recognized case-insensitively. (This is a change from PostgreSQL versions prior to 8.2, which were case-sensitive in some contexts but not others.) Neither timezone names nor abbreviations are hard-wired into the server; they are obtained from configuration files stored under .../share/timezone/ and .../share/timezonesets/ of the installation directory (see Section B.4).

在所有情况下，时区名称和缩写均不区分大小写。（这是对PostgreSQL8.2之前版本的更改，它们会在某些情况下区分大小写。）时区名称和缩写都不会硬连线到服务器中； 它们是从存储在安装目录的.../share/timezone/和.../share/timezonesets/下的配置文件获得的（请参阅第B.4节）。

 

The TimeZone configuration parameter can be set in the file postgresql.conf, or in any of the other standard ways described in Chapter 19. There are also some special ways to set it:

可以在文件postgresql.conf中设置TimeZone配置参数，也可以使用第19章中介绍的任何其他标准方式进行设置。还有一些特殊的设置方法：

 

• The SQL command SET TIME ZONE sets the time zone for the session. This is an alternative pelling of SET TIMEZONE TO with a more SQL-spec-compatible syntax.

•SQL命令SET TIME ZONE设置会话的时区。 这是SET TIMEZONE TO的另一种选择，它具有与SQL规范更加兼容的语法。

 

• The PGTZ environment variable is used by libpq clients to send a SET TIME ZONE command to the server upon connection.

•libpq客户端使用PGTZ环境变量在连接时将SET TIME ZONE命令发送到服务器。