From dbf57d31f8d7bf5c058a9fab2a1ccb4a336864ce Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sun, 9 Nov 2008 17:09:48 +0000 Subject: [PATCH] Add some documentation about handling of fractions in interval input. (It's always worked like this, but we never documented it before.) --- doc/src/sgml/datatype.sgml | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml index 10da67ef5c..d26fdc5fde 100644 --- a/doc/src/sgml/datatype.sgml +++ b/doc/src/sgml/datatype.sgml @@ -1,4 +1,4 @@ - + Data Types @@ -2413,13 +2413,26 @@ January 8 04:05:06 1999 PST 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 + time adjustment is involved. The months and days fields are integers + while the seconds field can store fractions. 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 ranges. + + + In the verbose input format, and in some fields of the more compact + input formats, field values can have fractional parts; for example + '1.5 week' or '01:02:03.45'. Such input is + converted to the appropriate number of months, days, and seconds + for storage. When this would result in a fractional number of + months or days, the fraction is added to the lower-order fields + using the conversion factors 1 month = 30 days and 1 day = 24 hours. + For example, '1.5 month' becomes 1 month and 15 days. + Only seconds will ever be shown as fractional on output. +