On 17/04/2022 08:58, Paul Eggert wrote:
Thanks, I installed that and then installed the attached, which merges
that with some documentation improvements that I drafted based on this
thread.
Thank you for further editing of docs. Please, fix a typo.
diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi
index 66689f43a9..8366689640 100644
--- a/doc/lispref/os.texi
+++ b/doc/lispref/os.texi
@@ -1687,14 +1660,18 @@ Time Conversion
than six arguments the @emph{last} argument is used as @var{zone} and
any other extra arguments are ignored, so that @code{(apply
#'encode-time (decode-time ...))} works. In this obsolescent
-convention, @var{zone} defaults to the current time zone rule
-(@pxref{Time Zone Rules}), and @var{dst} is treated as if it was
-@minus{}1.
+convention, @var{dst} is @minus{}1 and @var{zone} defaults to the
+current time zone rule (@pxref{Time Zone Rules}).
+When modernizing an obsolescent caller, ensure that the more-modern
+list equivalent contains 9 elements with a a @code{dst} element that
^^^
A typo: double "a".
+is @minus{}1, not @code{nil}.
+@lisp
+;; Try to compute the time four years from now.
+;; Watch out; this might not work as expected.
+(let ((time (decode-time)))
+ (setf (decoded-time-year time)
+ (+ (decoded-time-year time) 4))
+ time)
+@end lisp
+@noindent
+Unfortunately, this code might not work as expected if the resulting
+time is invalid due to daylight saving transitions, time zone changes,
+or missing leap days or leap seconds. For example, if executed on
+February 29, 2096 this code yields a nonexistent date because 2100 is
+not a leap year. To avoid some (though not all) of the problem, you
+can base calculations on the middle of the affected unit, e.g., start
+at July 1 when adding years.
If I get your idea correctly then "January, 31" + "1 month" should be
more impressive as impossible date. Year 2096 is too far in future. I am
unsure concerning expectation. Overflow arithmetic is described above
and e.g. JavaScript normalizes Date object in a similar fashion. The
special point is that elisp decoded time requires explicit normalization
however and 2100 is a good example that updating of any field may
"break" the date.
Alternatively, you can use the
+@file{calendar} and @file{time-date} libraries.
A remark loosely related to your patch. Earlier you mentioned missed
midnight due to time transition and suggested to use calendrical
functions in Org. I can not figure out which elisp function can help to
determine wall time for Aug 1 start of day in Cairo:
Africa/Cairo Thu Jul 31 21:59:59 2014 UT = Thu Jul 31 23:59:59 2014 EET
isdst=0 gmtoff=7200
Africa/Cairo Thu Jul 31 22:00:00 2014 UT = Fri Aug 1 01:00:00 2014
EEST isdst=1 gmtoff=10800
input: 2014-08-01 Africa/Cairo
(timezone may be implicit as the system one)
expected output: 01:00:00
