jeluf wrote:

Is this wiki public, can you provide a URL?

Suiwiki wrote:

No, Local instration.

But I read Parser.php and test some tiny proglam as below
<?php

print getenv('TZ')."<BR>";

?>
shows nothing on windows. and
<?php

print date('T')."<BR>";

?>
shows
東京(標準時)
in Shift-Jis Code on Japanese Windows! (above is UTF-8 Code)

This code may change earch local versions of windows...
on MacOSX or Linux shows "JST" this is correct.

So this may be PHP bug? I donno.
PHP Manul says just "date('T') shows timezone"
and doesn't say "timezone in code"....

• Bug 1943 has been marked as a duplicate of this bug. ***

comment from bug 1943:

Hello,

I use Mediawiki (in combination with XAMPP on MS XP) with Unicode. It works

fine, but

with one exception: if you insert a signature with --~~~~ it shows the
phrase "Westeurop䩳che Sommerzeit", but the right word would be "Westeuropäische
Sommerzeit". If I searched for the phrase in the MySQL-DB I found the article

and in

the datafield the phrase was wrote right. I tried to repair it but I could not

find

it in any configuration-file.

aholle wrote:

Hello,

My setup is XAMPP 1.14.12 on Windows 2000 and Mediawiki 1.5beta4. Generally it
works fine, too.
The signature --~~~~ also produces a phrase like "Westeurop䩳che Sommerzeit",
but the right word would be "Westeuropäische Sommerzeit". As this is not comming
from the MediaWiki source code it sounds like the Wiki takes it out of the
Windows time zone configuration but does not transfer it into Unicode correctly.

gangleri wrote:

sorry
blocks bug 3969

gangleri wrote:

� is
Unicode Character REPLACEMENT CHARACTER U+FFFD
http://www.fileformat.info/info/unicode/char/fffd/index.htm
HTML Entity (decimal) &#65533;
HTML Entity (hex) &#xfffd;
UTF-8 (hex) 0xEF 0xBF 0xBD (efbfbd)

Looks like the Windows 2000 is lacking support for the conversion of a Japanese codepage to Unicode, and
the localization data contains Unicode characters not supported in this version of Windows . As Windows
2000 does not know to which Unicode codepoint the JISX encoding maps to, it converts the rest to
replacement characters.

Or the server was not started with the correct OEM codepage, for example from an old legacy codepage
defined in the user's locale environment, so JISX codes are not correctly converted.

• Bug 10445 has been marked as a duplicate of this bug. ***

mr-smoke wrote:

(In reply to comment #9)

> *** Bug 10445 has been marked as a duplicate of this bug. ***

Indeed, I had missed that bug.

Does my suggestion seem acceptable to you ?
That is to say, edit Parser.php, lines 3701-3702 to :

$d = $wgContLang->timeanddate( date( 'YmdHis' ), false, false) .

' (' . utf8_encode(date( 'T' )) . ')';

utf8_encode does the job, in case the OS reports the timezone in a broken format.

utf8_encode() only works from ISO 8859-1, so it's not generally suitable. (For instance it will just corrupt the Japanese code.)

mr-smoke wrote:

True. Definitely a case of "Works For Me" that won't work elsewhere.
So basically I take it the OS should be set to use UTF-8 in order for this functino to work correctly ? Perhaps it would be worth filing a bug with PHP ... Should it not be PHP's job to make sure that its output conforms to its charset setting ?

EN.WP.ST47 wrote:

Is this upstream? Is this still a bug?

(In reply to comment #13)

Is this upstream? Is this still a bug?

We need someone with a Japanese Windows to install MediaWiki and try it out :-D Probably unlikely to ever happen so I think we should just close this bug report.