master 15a5cf9a9a 1/2: Stress difference of new and old ways to call `encode-time'

[Paul Eggert]

branch: master
commit 15a5cf9a9aa7798ee12ae96b8b6b4efe1562b57e
Author: Max Nikulin <manikulin@gmail.com>
Commit: Paul Eggert <eggert@cs.ucla.edu>

    Stress difference of new and old ways to call `encode-time'
    
    * doc/lispref/os.texi (Time Conversion): Add a warning that blind
    changing of code calling `encode-time' to use single list instead of
    multiple values may cause deferred bugs since it is common to use nil
    for ignored arguments such as DST in the old calling convention.
    * src/timefns.c (encode-time): Mention the warning added to the elisp
    reference in the docstring.
    
    Refactoring related to `encode-time' caused (bug#54731), so it is better
    to make apparent the difference between the recommended and the
    obsolescent ways to call the function.  More details concerning the
    purpose and limitations of the DST field are added after discussion with
    Paul Eggert in (bug#54764).
---
 doc/lispref/os.texi | 19 +++++++++++++++++++
 src/timefns.c       |  4 ++++
 2 files changed, 23 insertions(+)

diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi
index 30883402f9..66689f43a9 100644
--- a/doc/lispref/os.texi
+++ b/doc/lispref/os.texi
@@ -1707,6 +1707,25 @@ the latter to the former as follows:
 You can perform simple date arithmetic by using out-of-range values for
 @var{seconds}, @var{minutes}, @var{hour}, @var{day}, and @var{month};
 for example, day 0 means the day preceding the given month.
+
+The old and the new styles to call @code{encode-time} with the same
+values of time fields may give different results.  While modernizing
+code that uses obsolescent calling convention, ensure that the list
+argument contains 9 elements.  Pay special attention that the @code{dst}
+field does not use @code{nil} expecting that actual value will be
+guessed, pass @samp{-1} instead.  During normalizing of values to
+correct state of daylight saving time users may get time shift and even
+wrong date.  It may take months to discover such problem.  When
+called with multiple arguments, the function ignores equivalent of the
+@code{dst} value and @samp{-1} is effectively used.  The new way to call
+@code{encode-time} has an advantage that it is possible to resolve
+ambiguity around backward time shift by passing @code{nil} or @code{t}.
+Unfortunately there are enough cases across the world when a particular
+area is moved to another time zone with no change of daylight saving
+time state.  @code{encode-time} may signal an error in response to
+@code{t} passed as @code{dst}.  You have to pass @code{zone} explicitly
+as time offset in such case if default ambiguity resolution is not
+acceptable.
 @end defun
 
 @node Time Parsing
diff --git a/src/timefns.c b/src/timefns.c
index b061be0a78..9af89a512d 100644
--- a/src/timefns.c
+++ b/src/timefns.c
@@ -1631,6 +1631,10 @@ convention, DST and ZONE default to -1 and nil 
respectively.
 Years before 1970 are not guaranteed to work.  On some systems,
 year values as low as 1901 do work.
 
+See Info node `(elisp)Time Conversion' for description of a pitfall
+that can be faced during migration from the obsolescent to the new
+calling convention due to unconscious usage of nil for the DST argument.
+
 usage: (encode-time TIME &rest OBSOLESCENT-ARGUMENTS)  */)
   (ptrdiff_t nargs, Lisp_Object *args)
 {