bug#7905: 24.0.50; VC not updating file status properly anymore after commit from vc-dir

[Tim Van Holder]

On 1 February 2011 22:45, Glenn Morris <rgm@gnu.org> wrote:
> Tim Van Holder wrote:
>
>>>>   (encode-time 16 18 15 11 1 2011 2 nil 3600)
>>>>   (encode-time 16 18 15 11 1 2011 2 nil 0)
>>>> both return the same value "(19756 26280)"
> [...]
>> In order to do the (apparent) right thing, encode-time seems to rely
>> on mktime() to take $TZ into account (otherwise there is no point in
>> saving/restoring the environment with a specific TZ value).
>> However, lib/mktime.c (which is in use by my emacs build) does not
>> seem to refer to any timezone info at all - neither $TZ nor tm_zone is
>> referenced; it seems to rely on localtime() to deal with that. I guess
>> that's not the case for my localtime() (from glibc 2.3.6).
>
> FWIW I built the current trunk on a system with glibc 2.3.4, and the
> two above encode-times return two different values. So whatever it is,
> it's not related to the glibc version.

I ran some separate tests and glibc's mktime and localtime seem to
properly take time zone info into account, regardless of whether it
came from $TZ, setenv("TZ", ...) or set_time_zone_rule() as copied
from editfns.c. So things _should_ be working fine in encode-time.
So it looks like it's an interaction inside emacs breaking things.
Whatever it is, it seems to be triggered by display-time-mode. Before
that is run, everything works fine. After running it, all
CVS-controlled files are edited as far as VC knows. After running it
again (disabling the actual display-time-mode display), things do NOT
return to normal. But I don't immediately see anything in time.el that
would suggest a problem.
It's particularly annoying that noone seems to be able to reproduce
it... I give up - I'll just disable display-time-mode.