Display problem on Windows with time zones containing Non-ASCII characters.

Display problem on Windows with time zones containing Non-ASCII characters.

[Michael Schierl]

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

- Load emacs -Q on Windows, on German Windows XP
- M-x calendar
- Go to 21 June 2007, and press "h"
- you will see in minibuffer:

Thursday, June 21, 2007:  Summer Solstice 8:05pm (Westeurop\344ische
Normalzeit)

where the four characters "\344" are written in red.
(it should have been an ä).
- Go to scratch buffer, and evaluate
(current-time-zone) with C-j
- Result is
(7200 "Westeurop\344ische Normalzeit")

So there is a problem with the ä in "Westeuropäische". There is another
problem that the correct time zone text should have been
"Mitteleuropäische Sommerzeit" (CEST) instead of "Westeuropäische
Normalzeit" but since both use the same timezone offset (-0200) I don't
know if you can fix that one. Fixing the charset should be possible,
however.


Michael

PS: The umlaut appears correctly below in the mail buffer in recent
messages, but it did not in the minibuffer.

In GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600)
 of 2007-06-02 on RELEASE
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Ic:/gnuwin32/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: DEU
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Calendar

Minor modes in effect:
  encoded-kbd-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
M-x c a l e n d a r <return> <down> <down> <right>
<right> h M-x r e p o r <tab> <return>

Recent messages:
Loading easymenu...done
Loading holidays...done
Checking holidays...
Loading cal-hebrew...done
Loading cal-islam...done
Loading cal-china...done
No holidays known for Wednesday, June 20, 2007
Checking holidays...
Thursday, June 21, 2007:  Summer Solstice 8:05pm (Westeuropäische
Normalzeit)
Loading emacsbug...done

Re: Display problem on Windows with time zones containing Non-ASCII characters.

[Jason Rumney]

Michael Schierl wrote:
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:
>
> - Load emacs -Q on Windows, on German Windows XP
> - M-x calendar
> - Go to 21 June 2007, and press "h"
> - you will see in minibuffer:
>
> Thursday, June 21, 2007:  Summer Solstice 8:05pm (Westeurop\344ische
> Normalzeit)
>
>   

In current-time-zone (editfns.c), we have the following code:

#if defined HAVE_TM_ZONE || defined HAVE_TZNAME
      if (s)
    {
      /* On Japanese w32, we can get a Japanese string as time
         zone name.  Don't accept that.  */
      char *p;
      for (p = s; *p && (isalnum ((unsigned char)*p) || *p == ' '); ++p)
        ;
      if (p == s || *p)
        s = NULL;
    }
#endif

[...]

      return Fcons (make_number (offset), Fcons (build_string (s), Qnil));

So the same bug must have been reported in the past for the Japanese
locale on W32, but we covered it over by rejecting non alphanumeric
timezone names rather than fixing the bug by decoding them using
locale_coding_system. I guess w32 is the only system where localized
full timezone names are returned by the tzname call or tm_zone struct
member, which is why we only notice it there.

Re: Display problem on Windows with time zones containing Non-ASCII characters.

[Jason Rumney]

Jason Rumney wrote:
> So the same bug must have been reported in the past for the Japanese
> locale on W32, but we covered it over by rejecting non alphanumeric
> timezone names rather than fixing the bug by decoding them using
> locale_coding_system.

I think the following change should fix the problem. Can anyone more
familiar with the coding functions confirm that I am doing this
correctly. Some of the calls to code_convert_string_norecord use
make_unibyte_string rather than build_string, but I can't figure out
when it is appropriate to do one not the other - or are they equivalent?


*** editfns.c    09 May 2007 10:32:39 +0100    1.439.2.1
--- editfns.c    06 Jun 2007 00:42:04 +0100   
***************
*** 1974,1979 ****
--- 1974,1981 ----
        int offset = tm_diff (t, &gmt);
        char *s = 0;
        char buf[6];
+       Lisp_Object name;
+
  #ifdef HAVE_TM_ZONE
        if (t->tm_zone)
      s = (char *)t->tm_zone;
***************
*** 1984,2002 ****
  #endif
  #endif /* not HAVE_TM_ZONE */
 
- #if defined HAVE_TM_ZONE || defined HAVE_TZNAME
-       if (s)
-     {
-       /* On Japanese w32, we can get a Japanese string as time
-          zone name.  Don't accept that.  */
-       char *p;
-       for (p = s; *p && (isalnum ((unsigned char)*p) || *p == ' '); ++p)
-         ;
-       if (p == s || *p)
-         s = NULL;
-     }
- #endif
-
        if (!s)
      {
        /* No local time zone name is available; use "+-NNNN" instead.  */
--- 1986,1991 ----
***************
*** 2004,2010 ****
        sprintf (buf, "%c%02d%02d", (offset < 0 ? '-' : '+'), am/60, am%60);
        s = buf;
      }
!       return Fcons (make_number (offset), Fcons (build_string (s), Qnil));
      }
    else
      return Fmake_list (make_number (2), Qnil);
--- 1993,2002 ----
        sprintf (buf, "%c%02d%02d", (offset < 0 ? '-' : '+'), am/60, am%60);
        s = buf;
      }
!       name = code_convert_string_norecord (build_string (s),
!                                            Vlocale_coding_system, 0);
!
!       return Fcons (make_number (offset), name, Qnil));
      }
    else
      return Fmake_list (make_number (2), Qnil);