Moodle
  1. Moodle
  2. MDL-32632

userdate() returns corrupted string on Windows environment (patch)

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.9.17, 2.0.8, 2.1, 2.2
    • Fix Version/s: 2.3
    • Component/s: General, Language, Unicode
    • Labels:
    • Environment:
      Moodle 2.2.2, Windows 7, XAMPP Apache, PHP
    • Testing Instructions:
      Hide

      1/ install cs and ja lang packs on windows test server
      2/ find a page that shows localised data (list of discussions for example)
      3/ switch to Czech and Japanese and verify there are valid unicode chars displayed in dates

      Show
      1/ install cs and ja lang packs on windows test server 2/ find a page that shows localised data (list of discussions for example) 3/ switch to Czech and Japanese and verify there are valid unicode chars displayed in dates
    • Difficulty:
      Easy
    • Affected Branches:
      MOODLE_19_STABLE, MOODLE_20_STABLE, MOODLE_21_STABLE, MOODLE_22_STABLE
    • Fixed Branches:
      MOODLE_23_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      w23_MDL-32632_m23_windate
    • Rank:
      39562

      Description

      This issue was reported long ago as MDL-13389 but it's closed and still unresolved so reporting again.

      On every major version of Moodle running on Windows servers, userdate in moodlelib.php can return corrupted date string. The problem is that userdate is usually called with date format parameter defined in langconfig.php (encoded in UTF-8), passes it directly to strftime, then the result string is converted from Windows ANSI encoding to UTF-8.

      The problem doesn't appear in most languages where format strings contain ASCII characters only.

      en: $string['strftimedaydatetime'] = '%A, %d. %B %Y, %H:%M';
      fr: $string['strftimedaydatetime'] = '%A %d %B %Y, %H:%M';

      However, the locales of East Asian languages have non-ASCII characters in format strings. It's because they write year, month and day followed by words which mean year, month and day, rather than bare numbers.

      ja: $string['strftimedaydatetime'] = '%Y年 %m月 %d日(%A) %H:%M';
      zh: $string['strftimedaydatetime'] = '%Y年%m月%d日 %A %H:%M';
      ko: $string['strftimedaydatetime'] = '%Y년 %B %d일, %A, %p %I:%M';

      Currently userdate converts only the returned string from strftime, but it should also convert format parameter before passing it to strftime. Otherwise the final conversion is done on a mixture of local encoding and UTF-8. Userdate outputs corrupted string, or if it meets byte sequence that can't be converted, nothing is output where date should come.

      Added a simple patch to solve this problem. It converts $format passed to the function as parameter or obtained inside the function before calling strftime. And instancing textlib is deprecated now so changed the calls to the convert function to static.

      1. moodlelib.patch
        0.9 kB
        Yamashita Kōichi

        Issue Links

          Activity

          Yamashita Kōichi created issue -
          Yamashita Kōichi made changes -
          Field Original Value New Value
          Attachment moodlelib.patch [ 28013 ]
          Yamashita Kōichi made changes -
          Testing Instructions Set locale to one of East Asian languages on Windows server. If debugging is set to DEBUG_DEVELOPER it also outputs iconv errors.
          Description This issue was reported long ago as MDL-13389 but it's closed and still unresolved so reporting again.

          On every major version of Moodle running on Windows servers, userdate in moodlelib.php can return corrupted date string. The problem is that userdate is usually called with date format parameter defined in langconfig.php (encoded in UTF-8), passes it directly to strftime, then the result string is converted from Windows ANSI encoding to UTF-8.

          The problem doesn't appear in most languages where format strings contain ASCII characters only.

          en: $string['strftimedaydatetime'] = '%A, %d. %B %Y, %H:%M';
          fr: $string['strftimedaydatetime'] = '%A %d %B %Y, %H:%M';

          However, the locales East Asian languages have non-ASCII characters in format strings. It's because they write year, month and day followed by words which mean year, month and day, rather than bare numbers.

          ja: $string['strftimedaydatetime'] = '%Y年 %m月 %d日(%A) %H:%M';
          zh: $string['strftimedaydatetime'] = '%Y年%m月%d日 %A %H:%M';
          ko: $string['strftimedaydatetime'] = '%Y년 %B %d일, %A, %p %I:%M';

          Currently userdate converts only the returned string from strftime, but it should also convert format parameter before passing it to strftime. Otherwise the final conversion is done on a mixture of local encoding and UTF-8 and the result string is corrupted.

          Here is a simple patch to solve this problem. It converts $format passed to the function as parameter or obtained inside the function before calling strftime. And instancing textlib is deprecated now so changed the calls to the convert function to static.

          --- moodlelib.php.orig 2012-03-10 09:04:31.000000000 +0900
          +++ moodlelib.php 2012-04-25 22:06:24.990603700 +0900
          @@ -1946,6 +1946,12 @@
                   $format = get_string('strftimedaydatetime', 'langconfig');
               }
           
          + if ($CFG->ostype == 'WINDOWS') {
          + if ($localewincharset = get_string('localewincharset', 'langconfig')) {
          + $format = textlib::convert($format, 'utf-8', $localewincharset);
          + }
          + }
          +
               if (!empty($CFG->nofixday)) { // Config.php can force %d not to be fixed.
                   $fixday = false;
               } else if ($fixday) {
          @@ -1985,8 +1991,7 @@
           
              if ($CFG->ostype == 'WINDOWS') {
                  if ($localewincharset = get_string('localewincharset', 'langconfig')) {
          - $textlib = textlib_get_instance();
          - $datestring = $textlib->convert($datestring, $localewincharset, 'utf-8');
          + $datestring = textlib::convert($datestring, $localewincharset, 'utf-8');
                  }
              }
          This issue was reported long ago as MDL-13389 but it's closed and still unresolved so reporting again.

          On every major version of Moodle running on Windows servers, userdate in moodlelib.php can return corrupted date string. The problem is that userdate is usually called with date format parameter defined in langconfig.php (encoded in UTF-8), passes it directly to strftime, then the result string is converted from Windows ANSI encoding to UTF-8.

          The problem doesn't appear in most languages where format strings contain ASCII characters only.

          en: $string['strftimedaydatetime'] = '%A, %d. %B %Y, %H:%M';
          fr: $string['strftimedaydatetime'] = '%A %d %B %Y, %H:%M';

          However, the locales of East Asian languages have non-ASCII characters in format strings. It's because they write year, month and day followed by words which mean year, month and day, rather than bare numbers.

          ja: $string['strftimedaydatetime'] = '%Y年 %m月 %d日(%A) %H:%M';
          zh: $string['strftimedaydatetime'] = '%Y年%m月%d日 %A %H:%M';
          ko: $string['strftimedaydatetime'] = '%Y년 %B %d일, %A, %p %I:%M';

          Currently userdate converts only the returned string from strftime, but it should also convert format parameter before passing it to strftime. Otherwise the final conversion is done on a mixture of local encoding and UTF-8 and the result string is corrupted.

          Here is a simple patch to solve this problem. It converts $format passed to the function as parameter or obtained inside the function before calling strftime. And instancing textlib is deprecated now so changed the calls to the convert function to static.

          --- moodlelib.php.orig 2012-03-10 09:04:31.000000000 +0900
          +++ moodlelib.php 2012-04-25 22:06:24.990603700 +0900
          @@ -1946,6 +1946,12 @@
                   $format = get_string('strftimedaydatetime', 'langconfig');
               }
           
          + if ($CFG->ostype == 'WINDOWS') {
          + if ($localewincharset = get_string('localewincharset', 'langconfig')) {
          + $format = textlib::convert($format, 'utf-8', $localewincharset);
          + }
          + }
          +
               if (!empty($CFG->nofixday)) { // Config.php can force %d not to be fixed.
                   $fixday = false;
               } else if ($fixday) {
          @@ -1985,8 +1991,7 @@
           
              if ($CFG->ostype == 'WINDOWS') {
                  if ($localewincharset = get_string('localewincharset', 'langconfig')) {
          - $textlib = textlib_get_instance();
          - $datestring = $textlib->convert($datestring, $localewincharset, 'utf-8');
          + $datestring = textlib::convert($datestring, $localewincharset, 'utf-8');
                  }
              }
          Environment Moodle 2.2.2, Windows 7, XAMPP Apache, PHP
          Difficulty Easy [ 10023 ]
          Yamashita Kōichi made changes -
          Description This issue was reported long ago as MDL-13389 but it's closed and still unresolved so reporting again.

          On every major version of Moodle running on Windows servers, userdate in moodlelib.php can return corrupted date string. The problem is that userdate is usually called with date format parameter defined in langconfig.php (encoded in UTF-8), passes it directly to strftime, then the result string is converted from Windows ANSI encoding to UTF-8.

          The problem doesn't appear in most languages where format strings contain ASCII characters only.

          en: $string['strftimedaydatetime'] = '%A, %d. %B %Y, %H:%M';
          fr: $string['strftimedaydatetime'] = '%A %d %B %Y, %H:%M';

          However, the locales of East Asian languages have non-ASCII characters in format strings. It's because they write year, month and day followed by words which mean year, month and day, rather than bare numbers.

          ja: $string['strftimedaydatetime'] = '%Y年 %m月 %d日(%A) %H:%M';
          zh: $string['strftimedaydatetime'] = '%Y年%m月%d日 %A %H:%M';
          ko: $string['strftimedaydatetime'] = '%Y년 %B %d일, %A, %p %I:%M';

          Currently userdate converts only the returned string from strftime, but it should also convert format parameter before passing it to strftime. Otherwise the final conversion is done on a mixture of local encoding and UTF-8 and the result string is corrupted.

          Here is a simple patch to solve this problem. It converts $format passed to the function as parameter or obtained inside the function before calling strftime. And instancing textlib is deprecated now so changed the calls to the convert function to static.

          --- moodlelib.php.orig 2012-03-10 09:04:31.000000000 +0900
          +++ moodlelib.php 2012-04-25 22:06:24.990603700 +0900
          @@ -1946,6 +1946,12 @@
                   $format = get_string('strftimedaydatetime', 'langconfig');
               }
           
          + if ($CFG->ostype == 'WINDOWS') {
          + if ($localewincharset = get_string('localewincharset', 'langconfig')) {
          + $format = textlib::convert($format, 'utf-8', $localewincharset);
          + }
          + }
          +
               if (!empty($CFG->nofixday)) { // Config.php can force %d not to be fixed.
                   $fixday = false;
               } else if ($fixday) {
          @@ -1985,8 +1991,7 @@
           
              if ($CFG->ostype == 'WINDOWS') {
                  if ($localewincharset = get_string('localewincharset', 'langconfig')) {
          - $textlib = textlib_get_instance();
          - $datestring = $textlib->convert($datestring, $localewincharset, 'utf-8');
          + $datestring = textlib::convert($datestring, $localewincharset, 'utf-8');
                  }
              }
          This issue was reported long ago as MDL-13389 but it's closed and still unresolved so reporting again.

          On every major version of Moodle running on Windows servers, userdate in moodlelib.php can return corrupted date string. The problem is that userdate is usually called with date format parameter defined in langconfig.php (encoded in UTF-8), passes it directly to strftime, then the result string is converted from Windows ANSI encoding to UTF-8.

          The problem doesn't appear in most languages where format strings contain ASCII characters only.

          en: $string['strftimedaydatetime'] = '%A, %d. %B %Y, %H:%M';
          fr: $string['strftimedaydatetime'] = '%A %d %B %Y, %H:%M';

          However, the locales of East Asian languages have non-ASCII characters in format strings. It's because they write year, month and day followed by words which mean year, month and day, rather than bare numbers.

          ja: $string['strftimedaydatetime'] = '%Y年 %m月 %d日(%A) %H:%M';
          zh: $string['strftimedaydatetime'] = '%Y年%m月%d日 %A %H:%M';
          ko: $string['strftimedaydatetime'] = '%Y년 %B %d일, %A, %p %I:%M';

          Currently userdate converts only the returned string from strftime, but it should also convert format parameter before passing it to strftime. Otherwise the final conversion is done on a mixture of local encoding and UTF-8 and the result string is corrupted.

          Here is a simple patch to solve this problem. It converts $format passed to the function as parameter or obtained inside the function before calling strftime. And instancing textlib is deprecated now so changed the calls to the convert function to static.




          --- moodlelib.php.orig 2012-03-10 09:04:31.000000000 +0900
          +++ moodlelib.php 2012-04-25 22:06:24.990603700 +0900
          @@ -1946,6 +1946,12 @@
                   $format = get_string('strftimedaydatetime', 'langconfig');
               }
           
          + if ($CFG->ostype == 'WINDOWS') {
          + if ($localewincharset = get_string('localewincharset', 'langconfig')) {
          + $format = textlib::convert($format, 'utf-8', $localewincharset);
          + }
          + }
          +
               if (!empty($CFG->nofixday)) { // Config.php can force %d not to be fixed.
                   $fixday = false;
               } else if ($fixday) {
          @@ -1985,8 +1991,7 @@
           
              if ($CFG->ostype == 'WINDOWS') {
                  if ($localewincharset = get_string('localewincharset', 'langconfig')) {
          - $textlib = textlib_get_instance();
          - $datestring = $textlib->convert($datestring, $localewincharset, 'utf-8');
          + $datestring = textlib::convert($datestring, $localewincharset, 'utf-8');
                  }
              }
          Yamashita Kōichi made changes -
          Description This issue was reported long ago as MDL-13389 but it's closed and still unresolved so reporting again.

          On every major version of Moodle running on Windows servers, userdate in moodlelib.php can return corrupted date string. The problem is that userdate is usually called with date format parameter defined in langconfig.php (encoded in UTF-8), passes it directly to strftime, then the result string is converted from Windows ANSI encoding to UTF-8.

          The problem doesn't appear in most languages where format strings contain ASCII characters only.

          en: $string['strftimedaydatetime'] = '%A, %d. %B %Y, %H:%M';
          fr: $string['strftimedaydatetime'] = '%A %d %B %Y, %H:%M';

          However, the locales of East Asian languages have non-ASCII characters in format strings. It's because they write year, month and day followed by words which mean year, month and day, rather than bare numbers.

          ja: $string['strftimedaydatetime'] = '%Y年 %m月 %d日(%A) %H:%M';
          zh: $string['strftimedaydatetime'] = '%Y年%m月%d日 %A %H:%M';
          ko: $string['strftimedaydatetime'] = '%Y년 %B %d일, %A, %p %I:%M';

          Currently userdate converts only the returned string from strftime, but it should also convert format parameter before passing it to strftime. Otherwise the final conversion is done on a mixture of local encoding and UTF-8 and the result string is corrupted.

          Here is a simple patch to solve this problem. It converts $format passed to the function as parameter or obtained inside the function before calling strftime. And instancing textlib is deprecated now so changed the calls to the convert function to static.




          --- moodlelib.php.orig 2012-03-10 09:04:31.000000000 +0900
          +++ moodlelib.php 2012-04-25 22:06:24.990603700 +0900
          @@ -1946,6 +1946,12 @@
                   $format = get_string('strftimedaydatetime', 'langconfig');
               }
           
          + if ($CFG->ostype == 'WINDOWS') {
          + if ($localewincharset = get_string('localewincharset', 'langconfig')) {
          + $format = textlib::convert($format, 'utf-8', $localewincharset);
          + }
          + }
          +
               if (!empty($CFG->nofixday)) { // Config.php can force %d not to be fixed.
                   $fixday = false;
               } else if ($fixday) {
          @@ -1985,8 +1991,7 @@
           
              if ($CFG->ostype == 'WINDOWS') {
                  if ($localewincharset = get_string('localewincharset', 'langconfig')) {
          - $textlib = textlib_get_instance();
          - $datestring = $textlib->convert($datestring, $localewincharset, 'utf-8');
          + $datestring = textlib::convert($datestring, $localewincharset, 'utf-8');
                  }
              }
          This issue was reported long ago as MDL-13389 but it's closed and still unresolved so reporting again.

          On every major version of Moodle running on Windows servers, userdate in moodlelib.php can return corrupted date string. The problem is that userdate is usually called with date format parameter defined in langconfig.php (encoded in UTF-8), passes it directly to strftime, then the result string is converted from Windows ANSI encoding to UTF-8.

          The problem doesn't appear in most languages where format strings contain ASCII characters only.

          en: $string['strftimedaydatetime'] = '%A, %d. %B %Y, %H:%M';
          fr: $string['strftimedaydatetime'] = '%A %d %B %Y, %H:%M';

          However, the locales of East Asian languages have non-ASCII characters in format strings. It's because they write year, month and day followed by words which mean year, month and day, rather than bare numbers.

          ja: $string['strftimedaydatetime'] = '%Y年 %m月 %d日(%A) %H:%M';
          zh: $string['strftimedaydatetime'] = '%Y年%m月%d日 %A %H:%M';
          ko: $string['strftimedaydatetime'] = '%Y년 %B %d일, %A, %p %I:%M';

          Currently userdate converts only the returned string from strftime, but it should also convert format parameter before passing it to strftime. Otherwise the final conversion is done on a mixture of local encoding and UTF-8 and the result string is corrupted.

          Here is a simple patch to solve this problem. It converts $format passed to the function as parameter or obtained inside the function before calling strftime. And instancing textlib is deprecated now so changed the calls to the convert function to static.




          --- moodlelib.php.orig 2012-03-10 09:04:31.000000000 +0900

          +++ moodlelib.php 2012-04-25 22:06:24.990603700 +0900

          @@ -1946,6 +1946,12 @@

                   $format = get_string('strftimedaydatetime', 'langconfig');

               }

           

          + if ($CFG->ostype == 'WINDOWS') {

          + if ($localewincharset = get_string('localewincharset', 'langconfig')) {

          + $format = textlib::convert($format, 'utf-8', $localewincharset);

          + }

          + }

          +

               if (!empty($CFG->nofixday)) { // Config.php can force %d not to be fixed.

                   $fixday = false;

               } else if ($fixday) {

          @@ -1985,8 +1991,7 @@

           

              if ($CFG->ostype == 'WINDOWS') {

                  if ($localewincharset = get_string('localewincharset', 'langconfig')) {

          - $textlib = textlib_get_instance();

          - $datestring = $textlib->convert($datestring, $localewincharset, 'utf-8');

          + $datestring = textlib::convert($datestring, $localewincharset, 'utf-8');

                  }

              }
          Yamashita Kōichi made changes -
          Description This issue was reported long ago as MDL-13389 but it's closed and still unresolved so reporting again.

          On every major version of Moodle running on Windows servers, userdate in moodlelib.php can return corrupted date string. The problem is that userdate is usually called with date format parameter defined in langconfig.php (encoded in UTF-8), passes it directly to strftime, then the result string is converted from Windows ANSI encoding to UTF-8.

          The problem doesn't appear in most languages where format strings contain ASCII characters only.

          en: $string['strftimedaydatetime'] = '%A, %d. %B %Y, %H:%M';
          fr: $string['strftimedaydatetime'] = '%A %d %B %Y, %H:%M';

          However, the locales of East Asian languages have non-ASCII characters in format strings. It's because they write year, month and day followed by words which mean year, month and day, rather than bare numbers.

          ja: $string['strftimedaydatetime'] = '%Y年 %m月 %d日(%A) %H:%M';
          zh: $string['strftimedaydatetime'] = '%Y年%m月%d日 %A %H:%M';
          ko: $string['strftimedaydatetime'] = '%Y년 %B %d일, %A, %p %I:%M';

          Currently userdate converts only the returned string from strftime, but it should also convert format parameter before passing it to strftime. Otherwise the final conversion is done on a mixture of local encoding and UTF-8 and the result string is corrupted.

          Here is a simple patch to solve this problem. It converts $format passed to the function as parameter or obtained inside the function before calling strftime. And instancing textlib is deprecated now so changed the calls to the convert function to static.




          --- moodlelib.php.orig 2012-03-10 09:04:31.000000000 +0900

          +++ moodlelib.php 2012-04-25 22:06:24.990603700 +0900

          @@ -1946,6 +1946,12 @@

                   $format = get_string('strftimedaydatetime', 'langconfig');

               }

           

          + if ($CFG->ostype == 'WINDOWS') {

          + if ($localewincharset = get_string('localewincharset', 'langconfig')) {

          + $format = textlib::convert($format, 'utf-8', $localewincharset);

          + }

          + }

          +

               if (!empty($CFG->nofixday)) { // Config.php can force %d not to be fixed.

                   $fixday = false;

               } else if ($fixday) {

          @@ -1985,8 +1991,7 @@

           

              if ($CFG->ostype == 'WINDOWS') {

                  if ($localewincharset = get_string('localewincharset', 'langconfig')) {

          - $textlib = textlib_get_instance();

          - $datestring = $textlib->convert($datestring, $localewincharset, 'utf-8');

          + $datestring = textlib::convert($datestring, $localewincharset, 'utf-8');

                  }

              }
          This issue was reported long ago as MDL-13389 but it's closed and still unresolved so reporting again.

          On every major version of Moodle running on Windows servers, userdate in moodlelib.php can return corrupted date string. The problem is that userdate is usually called with date format parameter defined in langconfig.php (encoded in UTF-8), passes it directly to strftime, then the result string is converted from Windows ANSI encoding to UTF-8.

          The problem doesn't appear in most languages where format strings contain ASCII characters only.

          en: $string['strftimedaydatetime'] = '%A, %d. %B %Y, %H:%M';
          fr: $string['strftimedaydatetime'] = '%A %d %B %Y, %H:%M';

          However, the locales of East Asian languages have non-ASCII characters in format strings. It's because they write year, month and day followed by words which mean year, month and day, rather than bare numbers.

          ja: $string['strftimedaydatetime'] = '%Y年 %m月 %d日(%A) %H:%M';
          zh: $string['strftimedaydatetime'] = '%Y年%m月%d日 %A %H:%M';
          ko: $string['strftimedaydatetime'] = '%Y년 %B %d일, %A, %p %I:%M';

          Currently userdate converts only the returned string from strftime, but it should also convert format parameter before passing it to strftime. Otherwise the final conversion is done on a mixture of local encoding and UTF-8 and the result string is corrupted.

          Added a simple patch to solve this problem. It converts $format passed to the function as parameter or obtained inside the function before calling strftime. And instancing textlib is deprecated now so changed the calls to the convert function to static.
          Yamashita Kōichi made changes -
          Description This issue was reported long ago as MDL-13389 but it's closed and still unresolved so reporting again.

          On every major version of Moodle running on Windows servers, userdate in moodlelib.php can return corrupted date string. The problem is that userdate is usually called with date format parameter defined in langconfig.php (encoded in UTF-8), passes it directly to strftime, then the result string is converted from Windows ANSI encoding to UTF-8.

          The problem doesn't appear in most languages where format strings contain ASCII characters only.

          en: $string['strftimedaydatetime'] = '%A, %d. %B %Y, %H:%M';
          fr: $string['strftimedaydatetime'] = '%A %d %B %Y, %H:%M';

          However, the locales of East Asian languages have non-ASCII characters in format strings. It's because they write year, month and day followed by words which mean year, month and day, rather than bare numbers.

          ja: $string['strftimedaydatetime'] = '%Y年 %m月 %d日(%A) %H:%M';
          zh: $string['strftimedaydatetime'] = '%Y年%m月%d日 %A %H:%M';
          ko: $string['strftimedaydatetime'] = '%Y년 %B %d일, %A, %p %I:%M';

          Currently userdate converts only the returned string from strftime, but it should also convert format parameter before passing it to strftime. Otherwise the final conversion is done on a mixture of local encoding and UTF-8 and the result string is corrupted.

          Added a simple patch to solve this problem. It converts $format passed to the function as parameter or obtained inside the function before calling strftime. And instancing textlib is deprecated now so changed the calls to the convert function to static.
          This issue was reported long ago as MDL-13389 but it's closed and still unresolved so reporting again.

          On every major version of Moodle running on Windows servers, userdate in moodlelib.php can return corrupted date string. The problem is that userdate is usually called with date format parameter defined in langconfig.php (encoded in UTF-8), passes it directly to strftime, then the result string is converted from Windows ANSI encoding to UTF-8.

          The problem doesn't appear in most languages where format strings contain ASCII characters only.

          en: $string['strftimedaydatetime'] = '%A, %d. %B %Y, %H:%M';
          fr: $string['strftimedaydatetime'] = '%A %d %B %Y, %H:%M';

          However, the locales of East Asian languages have non-ASCII characters in format strings. It's because they write year, month and day followed by words which mean year, month and day, rather than bare numbers.

          ja: $string['strftimedaydatetime'] = '%Y年 %m月 %d日(%A) %H:%M';
          zh: $string['strftimedaydatetime'] = '%Y年%m月%d日 %A %H:%M';
          ko: $string['strftimedaydatetime'] = '%Y년 %B %d일, %A, %p %I:%M';

          Currently userdate converts only the returned string from strftime, but it should also convert format parameter before passing it to strftime. Otherwise the final conversion is done on a mixture of local encoding and UTF-8. iconv outputs corrupted string, or if it meets byte sequence that can't be converted, nothing is output where date should come.

          Added a simple patch to solve this problem. It converts $format passed to the function as parameter or obtained inside the function before calling strftime. And instancing textlib is deprecated now so changed the calls to the convert function to static.
          Yamashita Kōichi made changes -
          Description This issue was reported long ago as MDL-13389 but it's closed and still unresolved so reporting again.

          On every major version of Moodle running on Windows servers, userdate in moodlelib.php can return corrupted date string. The problem is that userdate is usually called with date format parameter defined in langconfig.php (encoded in UTF-8), passes it directly to strftime, then the result string is converted from Windows ANSI encoding to UTF-8.

          The problem doesn't appear in most languages where format strings contain ASCII characters only.

          en: $string['strftimedaydatetime'] = '%A, %d. %B %Y, %H:%M';
          fr: $string['strftimedaydatetime'] = '%A %d %B %Y, %H:%M';

          However, the locales of East Asian languages have non-ASCII characters in format strings. It's because they write year, month and day followed by words which mean year, month and day, rather than bare numbers.

          ja: $string['strftimedaydatetime'] = '%Y年 %m月 %d日(%A) %H:%M';
          zh: $string['strftimedaydatetime'] = '%Y年%m月%d日 %A %H:%M';
          ko: $string['strftimedaydatetime'] = '%Y년 %B %d일, %A, %p %I:%M';

          Currently userdate converts only the returned string from strftime, but it should also convert format parameter before passing it to strftime. Otherwise the final conversion is done on a mixture of local encoding and UTF-8. iconv outputs corrupted string, or if it meets byte sequence that can't be converted, nothing is output where date should come.

          Added a simple patch to solve this problem. It converts $format passed to the function as parameter or obtained inside the function before calling strftime. And instancing textlib is deprecated now so changed the calls to the convert function to static.
          This issue was reported long ago as MDL-13389 but it's closed and still unresolved so reporting again.

          On every major version of Moodle running on Windows servers, userdate in moodlelib.php can return corrupted date string. The problem is that userdate is usually called with date format parameter defined in langconfig.php (encoded in UTF-8), passes it directly to strftime, then the result string is converted from Windows ANSI encoding to UTF-8.

          The problem doesn't appear in most languages where format strings contain ASCII characters only.

          en: $string['strftimedaydatetime'] = '%A, %d. %B %Y, %H:%M';
          fr: $string['strftimedaydatetime'] = '%A %d %B %Y, %H:%M';

          However, the locales of East Asian languages have non-ASCII characters in format strings. It's because they write year, month and day followed by words which mean year, month and day, rather than bare numbers.

          ja: $string['strftimedaydatetime'] = '%Y年 %m月 %d日(%A) %H:%M';
          zh: $string['strftimedaydatetime'] = '%Y年%m月%d日 %A %H:%M';
          ko: $string['strftimedaydatetime'] = '%Y년 %B %d일, %A, %p %I:%M';

          Currently userdate converts only the returned string from strftime, but it should also convert format parameter before passing it to strftime. Otherwise the final conversion is done on a mixture of local encoding and UTF-8. Userdate outputs corrupted string, or if it meets byte sequence that can't be converted, nothing is output where date should come.

          Added a simple patch to solve this problem. It converts $format passed to the function as parameter or obtained inside the function before calling strftime. And instancing textlib is deprecated now so changed the calls to the convert function to static.
          Michael de Raadt made changes -
          Fix Version/s STABLE backlog [ 10463 ]
          Priority Minor [ 4 ] Major [ 3 ]
          Labels patch triaged
          Michael de Raadt made changes -
          Priority Major [ 3 ] Critical [ 2 ]
          Component/s Language [ 10089 ]
          Component/s Unicode [ 10094 ]
          Michael de Raadt made changes -
          Link This issue duplicates MDL-13389 [ MDL-13389 ]
          Michael de Raadt made changes -
          Link This issue duplicates MDL-14149 [ MDL-14149 ]
          Petr Škoda made changes -
          Assignee moodle.com [ moodle.com ] Petr Škoda (skodak) [ skodak ]
          Petr Škoda made changes -
          Status Open [ 1 ] Waiting for integration review [ 10010 ]
          Pull Master Diff URL https://github.com/skodak/moodle/compare/master...w19_MDL-32632_m23_windate
          Pull Master Branch w19_MDL-32632_m23_windate
          Pull from Repository git://github.com/skodak/moodle.git
          Fix Version/s 2.3 [ 10657 ]
          Fix Version/s STABLE backlog [ 10463 ]
          Testing Instructions Set locale to one of East Asian languages on Windows server. If debugging is set to DEBUG_DEVELOPER it also outputs iconv errors. 1/ install cs and ja lang packs on windows test server
          2/ find a page that shows localised data (list of discussions for example)
          3/ switch to Czech and Japanese and verify there are valid unicode chars displayed in dates
          Petr Škoda made changes -
          Pull Master Branch w19_MDL-32632_m23_windate w20_MDL-32632_m23_windate
          Petr Škoda made changes -
          Link This issue is duplicated by MDL-9901 [ MDL-9901 ]
          Petr Škoda made changes -
          Pull Master Diff URL https://github.com/skodak/moodle/compare/master...w22_MDL-32632_m23_windate https://github.com/skodak/moodle/compare/master...w23_MDL-32632_m23_windate
          Pull Master Branch w22_MDL-32632_m23_windate w23_MDL-32632_m23_windate
          Priority Critical [ 2 ] Major [ 3 ]
          Dan Poltawski made changes -
          Status Waiting for integration review [ 10010 ] Integration review in progress [ 10004 ]
          Integrator poltawski
          Currently in integration Yes [ 10041 ]
          Dan Poltawski made changes -
          Status Integration review in progress [ 10004 ] Waiting for testing [ 10005 ]
          Dan Poltawski made changes -
          Status Waiting for testing [ 10005 ] Testing in progress [ 10011 ]
          Tester poltawski
          Dan Poltawski made changes -
          Status Testing in progress [ 10011 ] Tested [ 10006 ]
          Dan Poltawski made changes -
          Link This issue will help resolve MDL-33545 [ MDL-33545 ]
          Eloy Lafuente (stronk7) made changes -
          Status Tested [ 10006 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Currently in integration Yes [ 10041 ]
          Integration date 12/Jun/12

            People

            • Votes:
              2 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: