Re: current-time-list now defaults to nil in Emacs master

On 2026-08-18 13:31, Stefan Monnier wrote:
>>> The better alternative (beside adjust the code so it works with the new
>>> format) is to insert a call to `time-convert`, as suggested in the
>>> `current-time` docstring.
>>
>> Some comments for the (my own) record
>> I spotted a difference (in "legacy code"),
> [...]
>> (setq current-time-list nil)
>>
>> (setq $a "Fri Aug 14 12:51:33 2026 +0530")
>> (let ((current-time-list t)) (encode-time (parse-time-string $a)))
>> ; (27262 49661)
>>
>> (time-convert (encode-time (parse-time-string $a)) 'list)
>> ;(27262 49661 0 0)
> 
> Interesting.  Paul, IIRC this is your code.  Is the discrepancy on purpose?

Yes, it's to be compatible with how encode-time worked starting in Emacs 19.29. Back then, Emacs generated timestamps in (HI LO USEC PSEC) format elsewhere, but encode-time was special: it generated (HI LO) format instead. (I vaguely recall that there were other special cases too, but do not remember the details.) When current-time-list is t Emacs replicates this traditional behavior unless the caller passes subsecond information to encode-time (a feature that Emacs 19.29 lacked).

When I added time-convert to Emacs I saw no need to support that (HI LO) format quirk, as there were no backward-compatibility concerns with the new time-convert function.


On 2026-08-17 20:43, Richard Stallman wrote:

> Idea: instead of changing the behavior of `current-time', etc, define
> new functions to handle timestamps the new way, and keep both sets
> permanently.

If we define new functions, I suggest they use a new timestamp format that is opaque to Lisp. Timestamps are a bit of a special case because they should be efficient so that we can time things more accurately, and making them opaque should help with that. (Not that I have time to take such a project on! :-)