Last modified: 2012-02-08 07:11:19 UTC
on WindowsXP, Apache system, ~~~~~ shows strange timezone name like
2004年10月20日 (水) 23:31 (���� (�W����))
I Guess, this is came from my windows is Japanese version and timezon is not UTC.
Is this wiki public, can you provide a URL?
No, Local instration.
But I read Parser.php and test some tiny proglam as below
shows nothing on windows. and
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:
> I use Mediawiki (in combination with XAMPP on MS XP) with Unicode. It works
> 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
> the datafield the phrase was wrote right. I tried to repair it but I could not
> it in any configuration-file.
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.
blocks bug 3969
Unicode Character REPLACEMENT CHARACTER U+FFFD
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
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.