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

[Bostjan Vilfan]

On Sun, Mar 17, 2013 at 8:47 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> 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.



Hello, and thanks for your message. I did as per your instructions,
and the value of

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

is "12:30 +0200 CDT" (actual local time was 11:30; so in other words
emacs thinks local time is 1 hour ahead of actual local time)

Your remark that all your Windows machines give the correct answer
indicates that there must be some settings on my computer that is at
fault; but I have no idea what that is.
I made one additional experiment: the version of emacs I was using was
a modification by Vincent Goulet
(http://vgoulet.act.ulaval.ca/en/emacs/). I thought that in some way
that version made some hidden changes, so I completely uninstalled it,
and installed the version obtainable from the GNU site. The result of
evaluating the above form was the same.
Regards,
Bostjan