mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Add detailed information on Australian time zones.

Browse Source
This commit is contained in:
Thomas G. Lockhart 2000-02-02 16:21:06 +00:00
parent 911fc20c41
commit fd54baa945
1 changed files with 196 additions and 158 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1,8 +1,11 @@
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/datetime.sgml,v 2.5 1999/10/12 13:57:04 thomas Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/datetime.sgml,v 2.6 2000/02/02 16:21:06 thomas Exp $
Date/time details Date/time details
$Log: datetime.sgml,v $ $Log: datetime.sgml,v $
Revision 2.6 2000/02/02 16:21:06 thomas
Add detailed information on Australian time zones.
Revision 2.5 1999/10/12 13:57:04 thomas Revision 2.5 1999/10/12 13:57:04 thomas
Sequence of date interpretation not quite right. Sequence of date interpretation not quite right.
@ -422,185 +425,220 @@ Finish initial markup of cvs.sgml, and include it in the programmer's guide
</tbody> </tbody>
</tgroup> </tgroup>
</table> </table>
<note>
<para>
If the compiler option USE_AUSTRALIAN_RULES is set
then <literal>EST</literal> refers to Australia Eastern Std Time,
which has an offset of +10:00 hours from UTC.
</para>
<para>
Australian time zones and their naming variants
account for fully one quarter of all time zones in the
<productname>Postgres</productname> time zone lookup table.
</para>
</note>
</para> </para>
<procedure> <sect2>
<title>Australian Time Zones</title>
<para>
Australian time zones and their naming variants
account for fully one quarter of all time zones in the
<productname>Postgres</productname> time zone lookup table.
There are two naming conflicts with common time zones defined
in the United States, <literal>CST</literal> and <literal>EST</literal>.
</para>
<para>
If the compiler option USE_AUSTRALIAN_RULES is set
then <literal>CST</literal> and <literal>EST</literal> will be
interpreted using Australian conventions.
<table tocentry="1">
<title><productname>Postgres</productname> Australian Time Zones</title>
<titleabbrev>Australian Time Zones</titleabbrev>
<tgroup cols="3">
<thead>
<row>
<entry>Time Zone</entry>
<entry>Offset from UTC</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry>CST</entry>
<entry>+10:30</entry>
<entry>Australian Central Standard Time</entry>
</row>
<row>
<entry>EST</entry>
<entry>+10:00</entry>
<entry>Australian Eastern Standard Time</entry>
</row>
</tbody>
</tgroup>
</table>
</para>
</sect2>
<sect2>
<title>Date/Time Input Interpretation</title> <title>Date/Time Input Interpretation</title>
<para> <para>
The date/time types are all decoded using a common set of routines. The date/time types are all decoded using a common set of routines.
</para> </para>
<step> <procedure>
<para> <title>Date/Time Input Interpretation</title>
Break the input string into tokens and categorize each token as
a string, time, time zone, or number.
</para>
<substeps> <step>
<step> <para>
<para> Break the input string into tokens and categorize each token as
If the token contains a colon (":"), this is a time string. a string, time, time zone, or number.
</para> </para>
</step>
<step> <substeps>
<para> <step>
If the token contains a dash ("-"), slash ("/"), or dot ("."), <para>
this is a date string which may have a text month. If the token contains a colon (":"), this is a time string.
</para> </para>
</step> </step>
<step> <step>
<para> <para>
If the token is numeric only, then it is either a single field If the token contains a dash ("-"), slash ("/"), or dot ("."),
or an ISO-8601 concatenated date (e.g. "19990113" for January 13, 1999) this is a date string which may have a text month.
or time (e.g. 141516 for 14:15:16). </para>
</para> </step>
</step>
<step>
<para>
If the token starts with a plus ("+") or minus ("-"),
then it is either a time zone or a special field.
</para>
</step>
</substeps>
</step>
<step> <step>
<para> <para>
If the token is a text string, match up with possible strings. If the token is numeric only, then it is either a single field
</para> or an ISO-8601 concatenated date (e.g. "19990113" for January 13, 1999)
or time (e.g. 141516 for 14:15:16).
</para>
</step>
<step>
<para>
If the token starts with a plus ("+") or minus ("-"),
then it is either a time zone or a special field.
</para>
</step>
</substeps>
</step>
<substeps> <step>
<step> <para>
<para> If the token is a text string, match up with possible strings.
Do a binary-search table lookup for the token </para>
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>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>.
</para>
</step>
<step> <substeps>
<para> <step>
If not found, do a similar binary-search table lookup to match <para>
the token with a time zone. Do a binary-search table lookup for the token
</para> as either a special string (e.g. <literal>today</literal>),
</step> day (e.g. <literal>Thursday</literal>),
month (e.g. <literal>January</literal>),
or noise word (e.g. <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>.
</para>
</step>
<step> <step>
<para> <para>
If not found, throw an error. If not found, do a similar binary-search table lookup to match
</para> the token with a time zone.
</step> </para>
</substeps> </step>
</step>
<step> <step>
<para> <para>
The token is a number or number field. If not found, throw an error.
</para> </para>
</step>
</substeps>
</step>
<substeps> <step>
<step> <para>
<para> The token is a number or number field.
If there are more than 4 digits, </para>
and if no other date fields have been previously read, then interpret
as a "concatenated date" (e.g. <literal>19990118</literal>). 8
and 6 digits are interpreted as year, month, and day, while 7
and 5 digits are interpreted as year, day of year, respectively.
</para>
</step>
<step> <substeps>
<para> <step>
If the token is three digits <para>
and a year has already been decoded, then interpret as day of year. If there are more than 4 digits,
</para> and if no other date fields have been previously read, then interpret
</step> as a "concatenated date" (e.g. <literal>19990118</literal>). 8
and 6 digits are interpreted as year, month, and day, while 7
and 5 digits are interpreted as year, day of year, respectively.
</para>
</step>
<step> <step>
<para> <para>
If longer than two digits, then interpret as a year. If the token is three digits
</para> and a year has already been decoded, then interpret as day of year.
</step> </para>
</step>
<step> <step>
<para> <para>
If in European date mode, and if the day field has not yet been read, If longer than two digits, then interpret as a year.
and if the value is less than or equal to 31, then interpret as a day. </para>
</para> </step>
</step>
<step> <step>
<para> <para>
If the month field has not yet been read, If in European date mode, and if the day field has not yet been read,
and if the value is less than or equal to 12, then interpret as a month. and if the value is less than or equal to 31, then interpret as a day.
</para> </para>
</step> </step>
<step> <step>
<para> <para>
If the day field has not yet been read, If the month field has not yet been read,
and if the value is less than or equal to 31, then interpret as a day. and if the value is less than or equal to 12, then interpret as a month.
</para> </para>
</step> </step>
<step> <step>
<para> <para>
Otherwise, interpret as a year. If the day field has not yet been read,
</para> and if the value is less than or equal to 31, then interpret as a day.
</step> </para>
</substeps> </step>
</step>
<step> <step>
<para> <para>
If BC has been specified, negate the year and offset by one for Otherwise, interpret as a year.
internal storage </para>
(there is no year zero in the Gregorian calendar, so numerically </step>
1BC becomes year zero). </substeps>
</para> </step>
</step>
<step> <step>
<para> <para>
If BC was not specified, and if the year field was two digits in length, then If BC has been specified, negate the year and offset by one for
adjust the year to 4 digits. If the field was less than 70, then add 2000; internal storage
otherwise, add 1900. (there is no year zero in the Gregorian calendar, so numerically
1BC becomes year zero).
</para>
</step>
<tip> <step>
<para> <para>
Gregorian years 1-99AD may be entered by using 4 digits with leading If BC was not specified, and if the year field was two digits in length, then
zeros (e.g. 0099 is 99AD). Three digits are also accepted as a adjust the year to 4 digits. If the field was less than 70, then add 2000;
year under most circumstances, though depending on position the otherwise, add 1900.
numeric string may
be interpreted as doy instead. <tip>
</para> <para>
</tip> Gregorian years 1-99AD may be entered by using 4 digits with leading
</para> zeros (e.g. 0099 is 99AD). Three digits are also accepted as a
</step> year under most circumstances, though depending on position the
</procedure> numeric string may
be interpreted as doy instead.
</para>
</tip>
</para>
</step>
</procedure>
</sect2>
</sect1> </sect1>
<sect1> <sect1>