From: Stefan Monnier <monnier@iro.umontreal.ca>
Date: Sun, 14 Aug 2022 14:41:40 +0000 (-0400)
Subject: * lisp/calendar/time-date.el (seconds-to-time): Use the original arg list
X-Git-Tag: emacs-29.0.90~1447^2~169
X-Git-Url: http://git.eshelyaron.com/gitweb/?a=commitdiff_plain;h=397fdc22eb140dd80e878528fd65e74da4033fa8;p=emacs.git

* lisp/calendar/time-date.el (seconds-to-time): Use the original arg list
---

diff --git a/lisp/calendar/time-date.el b/lisp/calendar/time-date.el
index 7e911d814dc..bbdcaa4db4e 100644
--- a/lisp/calendar/time-date.el
+++ b/lisp/calendar/time-date.el
@@ -171,13 +171,13 @@ If DATE lacks timezone information, GMT is assumed."
 	      (error "Invalid date: %s" date)))))))))
 
 ;;;###autoload
-(defalias 'time-to-seconds 'float-time)
+(defalias 'time-to-seconds #'float-time)
 
 ;;;###autoload
-(defun seconds-to-time (seconds &rest form)
-  "Convert SECONDS to a proper time, like `current-time' would.
-FORM means the same as in `time-convert'."
-  (time-convert seconds form))
+(defun seconds-to-time (seconds)
+  "Convert SECONDS to a proper time, like `current-time' would."
+  ;; FIXME: Should we (declare (obsolete time-convert "27.1")) ?
+  (time-convert seconds 'list))
 
 ;;;###autoload
 (defun days-to-time (days)
@@ -202,7 +202,7 @@ TIME should be either a time value or a date-time string."
   (time-subtract nil time))
 
 ;;;###autoload
-(define-obsolete-function-alias 'subtract-time 'time-subtract "26.1")
+(define-obsolete-function-alias 'subtract-time #'time-subtract "26.1")
 
 ;;;###autoload
 (defun date-to-day (date)
diff --git a/src/timefns.c b/src/timefns.c
index 7db50ea81cc..edfd73e9b80 100644
--- a/src/timefns.c
+++ b/src/timefns.c
@@ -401,6 +401,10 @@ decode_float_time (double t, struct lisp_time *result)
   else
     {
       int scale = double_integer_scale (t);
+      /* FIXME: `double_integer_scale` often returns values that are
+         "pessimistic" (i.e. larger than necessary), so 3.5 gets converted
+         to (7881299347898368 . 2251799813685248) rather than (7 . 2).
+         On 64bit systems, this should not matter very much, tho.  */
       eassume (scale < flt_radix_power_size);
 
       if (scale < 0)
@@ -1717,8 +1721,6 @@ DEFUN ("time-convert", Ftime_convert, Stime_convert, 1, 2, 0,
        doc: /* Convert TIME value to a Lisp timestamp of the given FORM.
 Truncate the returned value toward minus infinity.
 
-If FORM is nil, return the same form as `current-time'.
-
 If FORM is a positive integer, return a pair of integers (TICKS . FORM),
 where TICKS is the number of clock ticks and FORM is the clock frequency
 in ticks per second.
@@ -1731,9 +1733,14 @@ If FORM is `integer', return an integer count of seconds.
 If FORM is `list', return an integer list (HIGH LOW USEC PSEC), where
 HIGH has the most significant bits of the seconds, LOW has the least
 significant 16 bits, and USEC and PSEC are the microsecond and
-picosecond counts.  */)
+picosecond counts.
+
+If FORM is nil, the behavior depends on `current-time-list',
+but new code should not rely on it.  */)
      (Lisp_Object time, Lisp_Object form)
 {
+  /* FIXME: Any reason why we don't offer a `float` output format option as
+     well, since we accept it as input?  */
   struct lisp_time t;
   enum timeform input_form = decode_lisp_time (time, false, &t, 0);
   if (NILP (form))