From 7b53b45a643f466d2fe039dc0865a70d0f1d736e Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Thu, 22 Dec 2005 21:45:19 +0000 Subject: [PATCH] Update interval documenation to mention the storage system used. --- doc/src/sgml/datatype.sgml | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml index 03732ba9ca..811033cb59 100644 --- a/doc/src/sgml/datatype.sgml +++ b/doc/src/sgml/datatype.sgml @@ -1,5 +1,5 @@ @@ -1841,9 +1841,20 @@ January 8 04:05:06 1999 PST - The optional precision - p should be between 0 and 6, and - defaults to the precision of the input literal. + The optional subsecond precision p should + be between 0 and 6, and defaults to the precision of the input literal. + + + + Internally interval values are stored as months, days, + and seconds. This is done because the number of days in a month + varies, and a day can have 23 or 25 hours if a daylight savings + time adjustment is involved. Because intervals are usually created + from constant strings or timestamp subtraction, this + storage method works well in most cases. Functions + justify_days and justify_hours are + available for adjusting days and hours that overflow their normal + periods. @@ -1936,7 +1947,7 @@ January 8 04:05:06 1999 PST CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP, LOCALTIME, LOCALTIMESTAMP. The latter four accept an - optional precision specification. (See .) Note however that these are SQL functions and are not recognized as data input strings.