diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml index e8a6233277..24b169ba6a 100644 --- a/doc/src/sgml/datatype.sgml +++ b/doc/src/sgml/datatype.sgml @@ -1,5 +1,5 @@ @@ -1276,7 +1276,7 @@ SELECT b, char_length(b) FROM test2; - timestamp [ (p) ] without time zone + timestamp [ (p) ] [ without time zone ] both date and time 8 bytes 4713 BC @@ -1284,7 +1284,7 @@ SELECT b, char_length(b) FROM test2; 1 microsecond / 14 digits - timestamp [ (p) ] [ with time zone ] + timestamp [ (p) ] with time zone both date and time 8 bytes 4713 BC @@ -1293,7 +1293,7 @@ SELECT b, char_length(b) FROM test2; interval [ (p) ] - for time intervals + time intervals 12 bytes -178000000 years 178000000 years @@ -1334,16 +1334,22 @@ SELECT b, char_length(b) FROM test2; optional precision value p which specifies the number of fractional digits retained in the seconds field. By default, there is no explicit bound on precision. The - effective limit of precision is determined by the underlying double - precision floating-point number used to store values (in seconds - for interval and - in seconds since 2000-01-01 for timestamp). The - useful range of p is from 0 to about - 6 for timestamp, but may be more for interval. - The system will accept p ranging from - 0 to 13. + allowed range of p is from 0 to 6. + + + When timestamps are stored as double precision floating-point + numbers (currently the default), the effective limit of precision + may be less than 6, since timestamp values are stored as seconds + since 2000-01-01. Microsecond precision is achieved for dates within + a few years of 2000-01-01, but the precision degrades for dates further + away. When timestamps are stored as eight-byte integers (a compile-time + option), microsecond precision is available over the full range of + values. + + + Time zones, and time-zone conventions, are influenced by political decisions, not just earth geometry. Time zones around the