bug#21943: 25.1.50; Pcvs fails to list CVS entries

[Ivan Cibrario Bertolotti]

On 23 Nov 2015, at 20:01, Glenn Morris <rgm@gnu.org> wrote:
> 
> Ivan Cibrario Bertolotti wrote:
> 
>> When trying to list CVS entries using the pcvs builtin package,
>> for instance by means of the C-u <return> on any CVS directory
>> in a dired buffer, the following error message comes out:
>> 
>> cvs-fileinfo-from-entries: Invalid time zone specification: utc
>> 
>> The issue can probably be tracked down to the use of 'utc as third
>> argument of format-time-string at line 468 of pcvs-info.el.  Afaik,
>> the semantics of this argument have been changed in July 2015.
> 
> Thanks for the report. The pcvs fix is obvious, but it seems to me that
> this change to format-time-string should be called out in NEWS as in
> incompatible one. (Obviously it would be nicer if the change were
> backwards compatible.)

Thank you for your prompt reply.  As far as I know (just my 2 cents,
I’m in no way an Emacs Lisp expert) the changes introduced by
commit af32fa956267af40db61051c248597144d41521c
have been documented in NEWS, although the incompatibility has
not been explicitly called out.

More specifically, in Emacs 24.5.1, the third argument of
format-time-string was handled “as a Boolean”, that is, all non-nil
arguments were treated in the same way.

"if non-nil, means describe TIME as Universal Time; nil means
describe TIME in the local time zone”

In 25.1.50, a non-nil argument is further analyzed, looking for a
time zone rule or a few other special values.  Of them, t calls for
the old behavior.

"The optional ZONE is omitted or nil for Emacs local time, t for
Universal Time, ‘wall’ for system wall clock time, or a string as in
‘set-time-zone-rule’ for a time zone rule”

Therefore, I reckon that any call to format-time-string made in the
past with a third argument that is non-nil, not t, and does not
correspond to a valid time zone rule, is a potential source of
compatibility issues.

I do agree that the fix is obvious (most likely, just replace
any non-nil third argument with t), but it may require scanning the
code base for calls to format-time-string.

On the other hand, without introducing additional arguments, it may
be difficult to preserve backward compatibility because it is hard
to predict what programmers used as a “non-nil value” in the past.

Best regards,
ICB