Improve time zone documentation

* doc/lispref/os.texi (Time Zone Rules):
New section, mostly with material moved here from other sections.
* doc/emacs/cmdargs.texi (General Variables):
* doc/lispref/os.texi (Time Conversion, Time Parsing):
Xref new section.
* etc/NEWS, etc/PROBLEMS:
* lisp/org/org.el (org-timestamp-format):
* src/editfns.c (Fformat_time_string, Fdecode_time)
(Fencode_time, Fcurrent_time_string, Fcurrent_time_zone)
(Fset_time_zone_rule):
When documenting time zone rule strings, mention the TZ
environment variable in preference to mentioning the
sort-of-internal function set-time-zone-rule.

2 files changed, 9 insertions, 9 deletions

diff --git a/etc/NEWS b/etc/NEWS
index fe7df96ecea..bae42af6d6d 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1778,11 +1778,11 @@ quotation marks.
 *** Time conversion functions now accept an optional ZONE argument
 that specifies the time zone rules for conversion.  ZONE is omitted or
 nil for Emacs local time, t for Universal Time, 'wall' for system wall
-clock time, or a string as in 'set-time-zone-rule' for a time zone
-rule.  The affected functions are 'current-time-string',
-'current-time-zone', 'decode-time', and 'format-time-string'.  The
-function 'encode-time', which already accepted a simple time zone rule
-argument, has been extended to accept all the new forms.
+clock time, or a string as in the TZ environment variable.  The
+affected functions are 'current-time-string', 'current-time-zone',
+'decode-time', and 'format-time-string'.  The function 'encode-time',
+which already accepted a simple time zone rule argument, has been
+extended to accept all the new forms.
 
 *** Incompatible change in the third argument of 'format-time-string'.
 Previously, any non-nil argument was interpreted as specifying Universal Time.
diff --git a/etc/PROBLEMS b/etc/PROBLEMS
index b0c21ee25dd..be9400bf264 100644
--- a/etc/PROBLEMS
+++ b/etc/PROBLEMS
@@ -2220,11 +2220,11 @@ month names with consistent widths for some locales on some versions
 of Windows.  This is caused by a deficiency in the underlying system
 library function.
 
-** Problems with set-time-zone-rule function
+** Non-US time zones.
 
-The function set-time-zone-rule gives incorrect results for many
-non-US timezones.  This is due to over-simplistic handling of
-daylight savings switchovers by the Windows libraries.
+Many non-US time zones are implemented incorrectly.  This is due to
+over-simplistic handling of daylight savings switchovers by the
+Windows libraries.
 
 ** Files larger than 4GB report wrong size in a 32-bit Windows build