database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-30 11:03:19 +03:00
Code Activity

Fix up some problems in handling of zic-style time zone names in datetime

Browse Source 
input routines.  Remove the former "DecodePosixTimezone" function in favor of
letting the zic code handle POSIX-style zone specs (see tzparse()).  In
particular this means that "PST+3" now means the same as "-03", whereas it
used to mean "-11" --- the zone abbreviation is effectively just a noise word
in this syntax.  Make sure that all named and POSIX-style zone names will be
parsed as a single token.  Fix long-standing bogosities in printing and input
of fractional-hour timezone offsets (since the tzparse() code will accept
these, we'd better make 'em work).  Also correct an error in the original
coding of the zic-zone-name patch: in "timestamp without time zone" input,
zone names are supposed to be allowed but ignored, but the coding was such
that the zone changed the interpretation anyway.
This commit is contained in:
Tom Lane
2006-10-17 21:03:21 +00:00
parent d58f09e6b3
commit 022fd99668
8 changed files with 213 additions and 299 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
doc/src/sgml/datatype.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.177 2006/10/16 19:58:26 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.178 2006/10/17 21:03:20 tgl Exp $ -->
<chapter id="datatype">
<title id="datatype-title">Data Types</title>
@ -1675,12 +1675,16 @@ SELECT b, char_length(b) FROM test2;
<tbody>
<row>
<entry><literal>PST</literal></entry>
<entry>Pacific Standard Time</entry>
<entry>Abbreviation (for Pacific Standard Time)</entry>
</row>
<row>
<entry><literal>America/New_York</literal></entry>
<entry>Full time zone name</entry>
</row>
<row>
<entry><literal>PST8PDT</literal></entry>
<entry>POSIX-style time zone specification</entry>
</row>
<row>
<entry><literal>-8:00</literal></entry>
<entry>ISO-8601 offset for PST</entry>
@ -2183,7 +2187,7 @@ January 8 04:05:06 1999 PST
<listitem>
<para>
In addition to the timezone names and abbreviations,
<productname>PostgreSQL</productname> will accept time zone
<productname>PostgreSQL</productname> will accept POSIX-style time zone
specifications of the form <replaceable>STD</><replaceable>offset</> or
<replaceable>STD</><replaceable>offset</><replaceable>DST</>, where
<replaceable>STD</> is a zone abbreviation, <replaceable>offset</> is a
@ -2220,12 +2224,6 @@ January 8 04:05:06 1999 PST
prior to 8.2, which were case-sensitive in some contexts and not others.)
</para>
<para>
Note that timezone names are <emphasis>not</> used for date/time output
&mdash; all supported output formats use numeric timezone displays to
avoid ambiguity.
</para>
<para>
Neither full names nor abbreviations are hard-wired into the server;
they are obtained from configuration files stored under

30
doc/src/sgml/datetime.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/datetime.sgml,v 2.54 2006/09/22 16:35:55 tgl Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/datetime.sgml,v 2.55 2006/10/17 21:03:20 tgl Exp $ -->
<appendix id="datetime-appendix">
<title>Date/Time Support</title>
@ -46,9 +46,9 @@
<para>
If the numeric token contains a dash (<literal>-</>), slash
(<literal>/</>), or two or more dots (<literal>.</>), this is
a date string which may have a text month. In case of a slash
(<literal>/</>) it can also be a full time zone name like
<literal>America/New_York</>.
a date string which may have a text month. If a date token has
already been seen, it is instead interpreted as a time zone
name (e.g., <literal>America/New_York</>).
</para>
</step>
@ -64,7 +64,7 @@
<step>
<para>
If the token starts with a plus (<literal>+</>) or minus
(<literal>-</>), then it is either a time zone or a special
(<literal>-</>), then it is either a numeric time zone or a special
field.
</para>
</step>
@ -73,30 +73,24 @@
<step>
<para>
If the token is a text string, match up with possible strings.
If the token is a text string, match up with possible strings:
</para>
<substeps>
<step>
<para>
Do a binary-search table lookup for the token
as either a special string (e.g., <literal>today</literal>),
day (e.g., <literal>Thursday</literal>),
month (e.g., <literal>January</literal>),
or noise word (e.g., <literal>at</literal>, <literal>on</literal>).
</para>
<para>
Set field values and bit mask for fields.
For example, set year, month, day for <literal>today</literal>,
and additionally hour, minute, second for <literal>now</literal>.
Do a binary-search table lookup for the token as a time zone
abbreviation.
</para>
</step>
<step>
<para>
If not found, do a similar binary-search table lookup to match
the token with a time zone.
the token as either a special string (e.g., <literal>today</literal>),
day (e.g., <literal>Thursday</literal>),
month (e.g., <literal>January</literal>),
or noise word (e.g., <literal>at</literal>, <literal>on</literal>).
</para>
</step>