Wikimedia Bugzilla is closed!

Is this wiki public, can you provide a URL?

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.

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.

sorry
blocks bug 3969

� is
Unicode Character REPLACEMENT CHARACTER U+FFFD
http://www.fileformat.info/info/unicode/char/fffd/index.htm
HTML Entity (decimal)  	�
HTML Entity (hex) 	�
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. ***

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

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 ?

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.