From 42a20494e9f1461f7166c922452028548796bd16 Mon Sep 17 00:00:00 2001 From: Max Nikulin Date: Sat, 16 Apr 2022 23:19:10 +0700 Subject: [PATCH] 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 4ee893f860..b7b41f97ab 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) { -- 2.25.1