Tcl Source Code

ActiveTcl8.4.11
Windows2000(Japanese)

clock format 0 -format %Z
clock format 0 -format %X
clock format 0 -format %c
clock format 0 -format %x

clock format %c, %X and %Z output garbled string.
I read source code and found points of problems.
Next is details.

%Z
compat/strftime.c use multi-byte string.
But Windows TclpGetTZName returned UTF8 string.
And this string wasn't converted to muiti-byte.

%c %x %X
we should use LOCALE_USE_CP_ACP flag at GetDateFormat
in compat/strftime.c.
If system language wasn't same as locale option language,
clock format %c and %X output garbled string.
Of cource, this is a rare case, and if windows could not 
map locale encoding to system encoding, then we get
garbled string after all....


I' wrote patch for compat/strftime.c. please see it too.
thanks

Logged In: YES 
user_id=99768

I distinctly remember fixing this bug once before.  But the
fix wasn't
in the code.  I suspect that I fixed it on the 8.5 branch,
and then
eliminated TclpStrftime from that branch before I backported the
fix.  If so, that was downright slovenly.

Your patch looked nearly correct.  TclpGetTZName is supposed
to return UTF-8 on all platforms, so I eliminated the bit that
checked for WIN32.

Fix is only in core-8-4-branch; 8.5 works already.

Logged In: NO 

thank you kennykb.

%c %x %X
I thught that even if we got unicode, we must return it 
as multi-byte in strftime. It seemed to me that it was better 
than all garbage string. well, I entrust you entirely...orz

%Z
I checked Bug 624408 for a short time ago. thanks.
now 8.4.11, I can convert %Z format string to 
non-garbage string on tcl like this.
% set Z [clock format 0 -format %Z]
% encoding convertfrom utf-8 [encoding convertto [encoding
system] $Z]

Logged In: YES 
user_id=99768

Hmm, I need to find some of my old notes here.

In general, the Windows code tries to use the native Unicode
interfaces wherever possible, and in any case to convert to
UTF-8 as close to the system call as possible, so TcpGetTZName
is supposed to return UTF-8. LOCALE_USE_CP_ACP is
The Wrong Thing, since it will lose any characters that aren't
on the system ANSI code page.

It looks as if the right thing here will be to call
GetDateFormatW
if it's available (and then convert the resulting Unicode to
UTF-8).  On W98/Me systems that lack GetDateFormatW,
we need to do TclWinTCharToUtf on the TCHAR string
that's returned, and hope for the best.  (Or start requiring
MSLU - which would be my preference, since then Tcl
at least gets a consistent API to start from.)

At one point, we had a path through the code that caused
double conversion (interpreting a UTF-8 string as if it were
in system locale) which caused trouble.  That was bug 624408,
which got fixed quite some time ago by clarifying what
interfaces
return UTF-8.  This appears to be a case that we missed.

File Added - 151741: strftime.patch