Minor wordsmithing in datetime docs to try to address gripes raised by

cnliou.

diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index 7707aed2a47189d197582f5f23527f8516eabac1..a214f5398c8a331d53fe59441e14def031cf5218 100644 (file)
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -1,5 +1,5 @@
 
 
  
@@ -1301,7 +1301,7 @@ SELECT b, char_length(b) FROM test2;
         8 bytes
         both date and time
         4713 BC
-        AD 5874897
+        5874897 AD
         1 microsecond / 14 digits
        
        
@@ -1309,7 +1309,7 @@ SELECT b, char_length(b) FROM test2;
         8 bytes
         both date and time, with time zone
         4713 BC
-        AD 5874897
+        5874897 AD
         1 microsecond / 14 digits
        
        
@@ -1348,6 +1348,14 @@ SELECT b, char_length(b) FROM test2;
      
     
 
+   
+    
+     Prior to PostgreSQL 7.3, writing just
+     timestamp was equivalent to timestamp with
+     time zone.  This was changed for SQL compliance.
+    
+   
+
    
     time, timestamp, and
     interval accept an optional precision value
@@ -1363,23 +1371,16 @@ SELECT b, char_length(b) FROM test2;
     When timestamp values are stored as double precision floating-point
     numbers (currently the default), the effective limit of precision
     may be less than 6. timestamp values are stored as seconds
-    since 2000-01-01, and microsecond precision is achieved for dates within
-    a few years of 2000-01-01, but the precision degrades for dates further
-    away.  When timestamp values are stored as eight-byte integers (a compile-time
+    before or after midnight 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 timestamp values are stored as
+    eight-byte integers (a compile-time
     option), microsecond precision is available over the full range of
-    values. However eight-byte integer timestamps have a reduced range of
-    dates from 4713 BC up to 294276 AD.
+    values. However eight-byte integer timestamps have a more limited range of
+    dates than shown above: from 4713 BC up to 294276 AD.
    
    
 
-   
-    
-     Prior to PostgreSQL 7.3, writing just
-     timestamp was equivalent to timestamp with
-     time zone.  This was changed for SQL compliance.
-    
-   
-
    
     For the time types, the allowed range of
     p is from 0 to 6 when eight-byte integer

diff --git a/doc/src/sgml/datetime.sgml b/doc/src/sgml/datetime.sgml
index 93315564c86debe85e3ef3beb619a81801466f1d..d1f82c9d6e5509a32d5a0b2067e283742ddf78b9 100644 (file)
--- a/doc/src/sgml/datetime.sgml
+++ b/doc/src/sgml/datetime.sgml
@@ -1,5 +1,5 @@
 
 
  
@@ -370,15 +370,25 @@ $PostgreSQL: pgsql/doc/src/sgml/datetime.sgml,v 2.38 2003/11/29 19:51:36 pgsql E
 
    
      shows the time zone
-    abbreviations recognized by PostgreSQL.
-    PostgreSQL contains internal tabular
-    information for time zone decoding, since there is no standard
+    abbreviations recognized by PostgreSQL
+    in date/time input values.
+    PostgreSQL uses internal tables
+    for time zone input decoding, since there is no standard
     operating system interface to provide access to general,
     cross-time zone information. The underlying operating system
     is used to provide time zone information for
     output, however.
    
 
+   
+    Keep in mind also that the time zone names
+    recognized by SET TIMEZONE are operating-system
+    dependent and may have little to do with 
+    linkend="datetime-timezone-table">.  For example, some systems
+    recognize values like 'Europe/Rome' in SET
+    TIMEZONE.
+   
+
    
     The table is organized by time zone offset from UTC,
     rather than alphabetically.  This is intended to facilitate