bug#13982: 24.2; Bug in function format-time-string when used under Windows

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 16 Mar 2013 10:51:18 +0200
> From: Bostjan Vilfan <bjvilfan@gmail.com>
> 
> When the function format-time-string is tested under Linux after calling,
> e.g., "emacs -Q" by evaluating the form
> 
>     "(format-time-string \"%H:%M\")"
> 
> one gets the expected answer, i.e., the current local time since the two
> above mentioned variables are undefined.
> 
> However, when the same is performed under Windows, Emacs uses daylight
> savings with start and end corresponding to Cambridge, Massachusetts, in
> spite of the fact that the two previously mentioned variables are undefined.
> In my case I evaluated the above form at 9:47 AM local time but received the
> output 10:47, presumably because daylight savings time is already in force
> in Cambridge, Massachusetts, although not in the Central European Time area.

I don't think this has anything to do with either cal-dst or with any
of the calendar-daylight-savings-* variables.  format-time-string
doesn't look at any of that stuff.  It's all between Emacs and your
OS.

FWIW, I cannot reproduce this on any Windows machine to which I have
access (which includes Windows 7 and a couple of XP boxes).  In my
time zone, the DST is not yet in effect, either, but I don't see any
"Cambridge, Massachusetts" effect on the time string produced by
format-time-string.  I get the correct local time, the same one shown
by the OS on the task bar.

Please tell what do you get if you type the following in "emacs -Q",
without loading anything, neither cal-dst nor your sample init.el:

  M-: (format-time-string "%H:%M %z %Z") RET

Please also tell whether the result of the above matches the time zone
you defined for your system (which can be seen by double-clicking on
the time display in the task bar).

> Yet that is not all. (We are still refering to an installation of Emacs
> under Windows.) If one creates a small init.el file with the following
> contents:
> 
> START OF FILE
> (load "cal-dst")
> 
> (setq calendar-daylight-savings-starts '(calendar-nth-named-day -1 0 3 year))
> ;(setq calendar-daylight-savings-starts nil)
> (setq calendar-daylight-savings-ends '(calendar-nth-named-day -1 0 10 year))
> ;(setq calendar-daylight-savings-ends nil)
> (setq calendar-daylight-time-offset 60)
> (setq calendar-daylight-savings-starts-time 180)
> (setq calendar-daylight-savings-ends-time 180)
> END OF FILE
> 
> and invokes emacs with "runemacs --no-splash --no-site-file" (in that
> case the init.el will be executed), after which one evaluates the same
> form as before, one still gets the Cambridge, Massachusetts version of
> daylight savings. In other words, the two above mentioned variables have
> no effect.

That's right, they have no effect and _should_ have no effect.  So in
this part Emacs is surely behaving as expected.  The only problem
seems to be that Emacs thinks you are one hour ahead of your local
time, for some as yet unknown reason.