database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-11 20:28:21 +03:00
Code Activity

Include specific info on available timezones.

Browse Source 
Document date/time input parsing procedure.
This commit is contained in:
Thomas G. Lockhart
1999-05-04 02:22:13 +00:00
parent 2289b403aa
commit 1def28ff20
1 changed files with 269 additions and 232 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -520,10 +520,14 @@ This is set at compile time and may change in a future release.
<title>Date/Time Types</title> <title>Date/Time Types</title>
<para> <para>
There are two fundamental kinds of date and time measurements: There are two fundamental kinds of date and time measurements
provided by <productname>Postgres</productname>:
absolute clock times and relative time intervals. absolute clock times and relative time intervals.
Both kinds of quantities should have behaviors demonstrating both Both kinds of time measurements should demonstrate both
continuity and smoothness. continuity and smoothness.
</para>
<para>
<productname>Postgres</productname> supplies two primary user-oriented <productname>Postgres</productname> supplies two primary user-oriented
date and time types, date and time types,
<type>datetime</type> and <type>timespan</type>, as well as <type>datetime</type> and <type>timespan</type>, as well as
@ -677,10 +681,13 @@ for historical reasons.
</table> </table>
</para> </para>
<sect2>
<title>SQL92 Conventions</title>
<para> <para>
<productname>Postgres</productname> endeavors to be compatible with <productname>Postgres</productname> endeavors to be compatible with
<acronym>SQL92</acronym> definitions for typical usage. <acronym>SQL92</acronym> definitions for typical usage.
The <acronym>SQL92</acronym> standard has an odd mix of date and However, the <acronym>SQL92</acronym> standard has an odd mix of date and
time types and capabilities. Two obvious problems are: time types and capabilities. Two obvious problems are:
<itemizedlist> <itemizedlist>
@ -688,16 +695,20 @@ time types and capabilities. Two obvious problems are:
<para> <para>
Although the <type>date</type> type Although the <type>date</type> type
does not have an associated time zone, the does not have an associated time zone, the
<type>time</type> type can or does.</para></listitem> <type>time</type> type can or does.
</para>
</listitem>
<listitem> <listitem>
<para> <para>
The default time zone is specified as a constant integer offset The default time zone is specified as a constant integer offset
from GMT/UTC.</para></listitem> from GMT/UTC.
</para>
</listitem>
</itemizedlist> </itemizedlist>
However, time zones in the real world can have no meaning unless Time zones in the real world can have no meaning unless
associated with a date as well as a time associated with a date as well as a time
since the offset may vary through the year with daylight savings since the offset may vary through the year with daylight savings
time boundaries. time boundaries.
@ -724,6 +735,7 @@ being deprecated in favor of <type>timestamp</type> and <type>interval</type>.
The more arcane features of the date/time definitions from The more arcane features of the date/time definitions from
the <acronym>SQL92</acronym> standard are not likely to be pursued. the <acronym>SQL92</acronym> standard are not likely to be pursued.
</para> </para>
</sect2>
<sect2> <sect2>
<title>Date/Time Styles</title> <title>Date/Time Styles</title>
@ -838,6 +850,23 @@ In future releases, the default may become "ISO" (compatible with ISO-8601),
which alleviates date specification ambiguities and Y2K collation problems. which alleviates date specification ambiguities and Y2K collation problems.
</para> </para>
</sect2>
<sect2>
<title>Calendar</title>
<para>
<productname>Postgres</productname> uses Julian dates
for all date/time calculations. They have the nice property of correctly
predicting/calculating any date more recent than something like 4013BC
to far into the future, using the assumption that the length of the
year is 365.2425 days.
</para>
<para>
Date conventions before the 19th century make for interesting reading,
but are not consistant enough to warrant coding into a date/time handler.
</para>
</sect2> </sect2>
<sect2> <sect2>
@ -845,11 +874,19 @@ which alleviates date specification ambiguities and Y2K collation problems.
<para> <para>
<productname>Postgres</productname> obtains time zone support <productname>Postgres</productname> obtains time zone support
from the underlying operating system. from the underlying operating system for dates between 1902 and
All dates and times are stored internally in Universal Coordinated Time (UTC), 2038 (near the typical date limits for Unix-style
systems). Outside of this range, all dates are assumed to be
specified and used in Universal Coordinated Time (UTC).
</para>
<para>
All dates and times are stored internally in Universal UTC,
alternately known as Greenwich Mean Time (GMT). alternately known as Greenwich Mean Time (GMT).
Times are converted to local time on the database server before being Times are converted to local time on the database server before being
sent to the client frontend, hence by default are in the server time zone.</para> sent to the client frontend, hence by default are in the server
time zone.
</para>
<para> <para>
There are several ways to affect the time zone behavior: There are several ways to affect the time zone behavior: