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

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

[Bostjan Vilfan]

--text follows this line--
This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org.  Please check that
the From: line contains a valid email address.  After a delay of up
to one day, you should receive an acknowledgement at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

evaluate the form (format-time-string "%H:%M ")

DETAILS:
The behavior of Emacs with regard to daylight savings is covered in
section 31.13 of the manual. Briefly, the two most important variables are
calendar-daylight-savings-starts and calendar-daylight-savings-ends,
which are defined in cal-dst. If these variables are nil (or undefined,
when cal-dst is not loaded), daylight savings is not used; otherwise,
they define the start and end of daylight savings time. The default
value for the two variables corresponds to daylight savings in Cambridge,
Massachusetts.

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.

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.


In GNU Emacs 24.2.1 (i386-mingw-nt6.1.7601)
 of 2012-08-29 on MARVIN
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.6) --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Info

Minor modes in effect:
  server-mode: t
  show-paren-mode: t
  delete-selection-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<down-mouse-1> <mouse-1> <backspace> <return> <help-echo>
<help-echo> <help-echo> <help-echo> <down-mouse-1>
<mouse-1> <down-mouse-1> <mouse-1> SPC <kp-delete>
<down-mouse-1> <mouse-1> <backspace> <return> <down-mouse-1>
<mouse-1> <kp-delete> SPC <down-mouse-1> <mouse-movement>
<mouse-1> SPC <kp-delete> <help-echo> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<help-echo> <help-echo> <help-echo> <down-mouse-1>
<mouse-1> SPC ( <backspace> <backspace> <down-mouse-1>
<mouse-1> ( W r SPC <backspace> <backspace> e SPC a
r e SPC s t i l l SPC r e f e r i n g SPC t o SPC a
n SPC i n s t a l l a t i o n SPC o f SPC E m a c s
<return> <down-mouse-1> <mouse-1> <kp-delete> SPC <down-mouse-1>
<mouse-1> <return> <up> u n d e r SPC W i n d o w s
. ) SPC <kp-delete> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <tool-bar> <save-buffer> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<tool-bar> <make-frame> <switch-frame> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <menu-bar> <help-menu> <emacs-manual>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <help-echo> <down-mouse-1> <mouse-movement>
<mouse-1> C-s b u g C-s <help-echo> <down-mouse-1>
<mouse-2> <help-echo> <down-mouse-1> <mouse-2> <help-echo>
M-x r e p o r t - e m a c s - b u g <return>

Recent messages:
Saving file m:/orgmode/notes.org...
Wrote m:/orgmode/notes.org
org-agenda-error: Command not allowed in this line
create calendar tool bar item
GNU Emacs 24.2.1 (i386-mingw-nt6.1.7601) of 2012-08-29 on MARVIN
Connection file "c:/Users/Bostjan/Documents/.emacs.d/server/server" deleted
Server mode enabled
Saving file c:/Users/Bostjan/Documents/.emacs.d/daylight-savings-message.txt...
Wrote c:/Users/Bostjan/Documents/.emacs.d/daylight-savings-message.txt
Mark saved where search started

Load-path shadows:
c:/Program Files (x86)/GNU/Emacs/org-7.9.2/contrib/lisp/htmlize hides
c:/PROGRAM FILES (X86)/GNU/EMACS/EMACS24.2M/site-lisp/htmlize

Features:
(shadow sort mail-extr emacsbug message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
misearch multi-isearch info cus-start cus-load org-colview htmlize-view
w32-winprint htmlize cl holidays hol-loaddefs diary-lib diary-loaddefs
cal-iso mule-util cal-move org-wl org-w3m org-vm org-rmail org-mhe
org-mew org-irc org-jsinfo org-infojs org-html org-exp ob-exp
org-exp-blocks org-agenda org-info org-gnus gnus-util org-docview
org-bibtex bibtex org-bbdb org byte-opt bytecomp byte-compile cconv
macroexp advice help-fns advice-preload ob-tangle ob-ref ob-lob ob-table
org-footnote org-src ob-comint ob-keys org-pcomplete pcomplete comint
ansi-color ring org-list org-faces org-entities noutline outline
easy-mmode org-version ob-emacs-lisp ob org-compat org-macs ob-eval
format-spec find-func warnings server org-install cal-dst regexp-opt
cal-menu easymenu calendar cal-loaddefs paren delsel time-date tooltip
ediff-hook vc-hooks lisp-float-type mwheel dos-w32 disp-table ls-lisp
w32-win w32-vars tool-bar dnd fontset image fringe lisp-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process multi-tty emacs)

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

[Eli Zaretskii]

> 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.

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

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

[Eli Zaretskii]

> Date: Tue, 19 Mar 2013 12:56:30 +0200
> From: Bostjan Vilfan <bjvilfan@gmail.com>
> Cc: 13982@debbugs.gnu.org
> 
> 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 don't think there's a Windows time zone whose name is "CDT".  Can
you check if you happen to have a TZ variable in the environment, and
if so, what's its value?  Please look both in the Computer's
Properties and in the command shell from which you invoke "emacs -Q".

Also, I asked you to tell which time zone do you see in the Date/Time
dialog of your Windows system.  Right-click on the time display in the
right corner of your task bar, and select "Adjust date/time".  In the
dialog that pops, click "Change timezone", and tell the name of your
current Windows time zone that is shown in the middle of the dialog.

If the Windows time zone and the time zone given to Emacs are
different, you can have all kinds of "1 hour off" problems, especially
around daylight savings change date.

> 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.

Which leaves your system as the prime suspect.

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

[Bostjan Vilfan]

On Tue, Mar 19, 2013 at 7:02 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 19 Mar 2013 12:56:30 +0200
>> From: Bostjan Vilfan <bjvilfan@gmail.com>
>> Cc: 13982@debbugs.gnu.org
>>
>> 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 don't think there's a Windows time zone whose name is "CDT".  Can
> you check if you happen to have a TZ variable in the environment, and
> if so, what's its value?  Please look both in the Computer's
> Properties and in the command shell from which you invoke "emacs -Q".
>
TZ=CET-1CDT,3,-1,0,7200,10,-1,0,10800,3600

the reason I need TZ is that I still use the (quite old) RCS software.
Up to now I did not encounter any problems with TZ. With regard to
"CDT", I may have improvised a bit with the daylight savings name for
my timezone.

> Also, I asked you to tell which time zone do you see in the Date/Time
> dialog of your Windows system.  Right-click on the time display in the
> right corner of your task bar, and select "Adjust date/time".  In the
> dialog that pops, click "Change timezone", and tell the name of your
> current Windows time zone that is shown in the middle of the dialog.
>
> If the Windows time zone and the time zone given to Emacs are
> different, you can have all kinds of "1 hour off" problems, especially
> around daylight savings change date.
>
there is no abbreviation, just the following:

(UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna

>> 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.
>
> Which leaves your system as the prime suspect.

Hello,
I hope I answered your specific questions above. There is one item
that comes to mind, though, which I don't know whether it is evident
in the data in my original error report, namely, that my system is
64-bit Windows 7. I also have a 32-bit Windows 7 installation, but
currently I am unable to access it. As soon as I will be able to do
so, I will check how emacs behaves there.
Regards,
Bostjan

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

[Eli Zaretskii]

> Date: Tue, 19 Mar 2013 22:08:25 +0200
> From: Bostjan Vilfan <bjvilfan@gmail.com>
> Cc: 13982@debbugs.gnu.org
> 
> On Tue, Mar 19, 2013 at 7:02 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Date: Tue, 19 Mar 2013 12:56:30 +0200
> >> From: Bostjan Vilfan <bjvilfan@gmail.com>
> >> Cc: 13982@debbugs.gnu.org
> >>
> >> 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 don't think there's a Windows time zone whose name is "CDT".  Can
> > you check if you happen to have a TZ variable in the environment, and
> > if so, what's its value?  Please look both in the Computer's
> > Properties and in the command shell from which you invoke "emacs -Q".
> >
> TZ=CET-1CDT,3,-1,0,7200,10,-1,0,10800,3600

That's your problem, right there: unset that variable, and Emacs will
show the correct time.  The Windows runtime library includes
semi-broken support for setting TZ, but it only supports the
"CET-1CDT" part of the value, and so switches to daylight savings not
on the date that the rest of your value provides, but uses some
internal default dates.  See also this KB article:

  http://support.microsoft.com/kb/932590

> the reason I need TZ is that I still use the (quite old) RCS software.

There's a newer one here:

  http://sourceforge.net/projects/ezwinports/files/rcs-5.7-1-bin.zip/download

I use it all the time, and never needed any TZ setting.

> > Also, I asked you to tell which time zone do you see in the Date/Time
> > dialog of your Windows system.  Right-click on the time display in the
> > right corner of your task bar, and select "Adjust date/time".  In the
> > dialog that pops, click "Change timezone", and tell the name of your
> > current Windows time zone that is shown in the middle of the dialog.
> >
> > If the Windows time zone and the time zone given to Emacs are
> > different, you can have all kinds of "1 hour off" problems, especially
> > around daylight savings change date.
> >
> there is no abbreviation, just the following:
> 
> (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna

This is what %Z should produce in Emacs.  And it will, after you unset
TZ in the environment.

> I hope I answered your specific questions above. There is one item
> that comes to mind, though, which I don't know whether it is evident
> in the data in my original error report, namely, that my system is
> 64-bit Windows 7. I also have a 32-bit Windows 7 installation, but
> currently I am unable to access it. As soon as I will be able to do
> so, I will check how emacs behaves there.

32-bit vs 64-bit is not a factor here.  The problems you have happen
because you have TZ set in the environment.

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

[Bostjan Vilfan]

On Tue, Mar 19, 2013 at 9:58 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 19 Mar 2013 22:08:25 +0200
>> From: Bostjan Vilfan <bjvilfan@gmail.com>
>> Cc: 13982@debbugs.gnu.org
>>
>> On Tue, Mar 19, 2013 at 7:02 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> Date: Tue, 19 Mar 2013 12:56:30 +0200
>> >> From: Bostjan Vilfan <bjvilfan@gmail.com>
>> >> Cc: 13982@debbugs.gnu.org
>> >>
>> >> 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 don't think there's a Windows time zone whose name is "CDT".  Can
>> > you check if you happen to have a TZ variable in the environment, and
>> > if so, what's its value?  Please look both in the Computer's
>> > Properties and in the command shell from which you invoke "emacs -Q".
>> >
>> TZ=CET-1CDT,3,-1,0,7200,10,-1,0,10800,3600
>
> That's your problem, right there: unset that variable, and Emacs will
> show the correct time.  The Windows runtime library includes
> semi-broken support for setting TZ, but it only supports the
> "CET-1CDT" part of the value, and so switches to daylight savings not
> on the date that the rest of your value provides, but uses some
> internal default dates.  See also this KB article:
>
>   http://support.microsoft.com/kb/932590
>
>> the reason I need TZ is that I still use the (quite old) RCS software.
>
> There's a newer one here:
>
>   http://sourceforge.net/projects/ezwinports/files/rcs-5.7-1-bin.zip/download
>
> I use it all the time, and never needed any TZ setting.
>
>> > Also, I asked you to tell which time zone do you see in the Date/Time
>> > dialog of your Windows system.  Right-click on the time display in the
>> > right corner of your task bar, and select "Adjust date/time".  In the
>> > dialog that pops, click "Change timezone", and tell the name of your
>> > current Windows time zone that is shown in the middle of the dialog.
>> >
>> > If the Windows time zone and the time zone given to Emacs are
>> > different, you can have all kinds of "1 hour off" problems, especially
>> > around daylight savings change date.
>> >
>> there is no abbreviation, just the following:
>>
>> (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna
>
> This is what %Z should produce in Emacs.  And it will, after you unset
> TZ in the environment.
>
>> I hope I answered your specific questions above. There is one item
>> that comes to mind, though, which I don't know whether it is evident
>> in the data in my original error report, namely, that my system is
>> 64-bit Windows 7. I also have a 32-bit Windows 7 installation, but
>> currently I am unable to access it. As soon as I will be able to do
>> so, I will check how emacs behaves there.
>
> 32-bit vs 64-bit is not a factor here.  The problems you have happen
> because you have TZ set in the environment.

Hello,
Let me just say one huge thanks. I've also downloaded the newer
version of rcs, and hope it works.
Regards,
Bostjan

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

[Eli Zaretskii]

> Date: Wed, 20 Mar 2013 08:56:18 +0100
> From: Bostjan Vilfan <bjvilfan@gmail.com>
> Cc: 13982@debbugs.gnu.org
> 
> Let me just say one huge thanks. I've also downloaded the newer
> version of rcs, and hope it works.

So I guess your problem is fixed, and I'm therefore closing this bug.