Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-32632

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

    Details

    • Type: Bug
    • Status: Closed
    • Priority: 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

      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.

        Gliffy Diagrams

        1. moodlelib.patch
          0.9 kB
          Yamashita Kōichi

          Issue Links

            Activity

            k-yama Yamashita Kōichi created issue -
            k-yama Yamashita Kōichi made changes -
            Field Original Value New Value
            Attachment moodlelib.patch [ 28013 ]
            k-yama 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 ]
            k-yama 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');
                    }
                }
            k-yama 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');

                    }

                }
            k-yama 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.
            k-yama 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.
            k-yama 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.
            salvetore Michael de Raadt made changes -
            Fix Version/s STABLE backlog [ 10463 ]
            Priority Minor [ 4 ] Major [ 3 ]
            Labels patch triaged
            salvetore Michael de Raadt made changes -
            Priority Major [ 3 ] Critical [ 2 ]
            Component/s Language [ 10089 ]
            Component/s Unicode [ 10094 ]
            salvetore Michael de Raadt made changes -
            Link This issue duplicates MDL-13389 [ MDL-13389 ]
            salvetore Michael de Raadt made changes -
            Link This issue duplicates MDL-14149 [ MDL-14149 ]
            skodak Petr Skoda made changes -
            Assignee moodle.com [ moodle.com ] Petr Škoda (skodak) [ skodak ]
            skodak Petr Skoda 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
            skodak Petr Skoda made changes -
            Pull Master Branch w19_MDL-32632_m23_windate w20_MDL-32632_m23_windate
            skodak Petr Skoda made changes -
            Link This issue is duplicated by MDL-9901 [ MDL-9901 ]
            skodak Petr Skoda 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 ]
            poltawski Dan Poltawski made changes -
            Status Waiting for integration review [ 10010 ] Integration review in progress [ 10004 ]
            Integrator poltawski
            Currently in integration Yes [ 10041 ]
            poltawski Dan Poltawski made changes -
            Status Integration review in progress [ 10004 ] Waiting for testing [ 10005 ]
            poltawski Dan Poltawski made changes -
            Status Waiting for testing [ 10005 ] Testing in progress [ 10011 ]
            Tester poltawski
            poltawski Dan Poltawski made changes -
            Status Testing in progress [ 10011 ] Tested [ 10006 ]
            poltawski Dan Poltawski made changes -
            Link This issue will help resolve MDL-33545 [ MDL-33545 ]
            stronk7 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:
                  Fix Release Date:
                  25/Jun/12