> In Windows, text-mode applications are to use DOS encoding (in MS
> terms - OEM codepage), while GUI apps use Windows encoding (in MS
> terms - ANSI codepage)
> Win32 API offers OEMtoChar and CharToOEM functions to transcode messages.
Yes - but the output of a console program is not always viewed in the
console itself, see below.
> Again, for English and most of European languages, DOS and Windows
> encodings are the same, ...
Thats only true for the plain ascii part of the codepages.
On a german windows, the output for "CEST" is:
"Local Time is: Thu Sep 08 18:33:09 2005 Westeuropäische Sommerzeit"
but in the console this looks like:
"Local Time is: Thu Sep 08 18:33:09 2005 Westeuropõische Sommerzeit"
The tzset() routine in MSVCRT.DLL calls
GetTimeZoneInformation(TIME_ZONE_INFORMATION *) and sets tzname[0/1]
from TIME_ZONE_INFORMATION.Standard/DaylightName by default.
These strings do not contain the usual 3-4 letter timezone abbreviations
but some longer name in national language and charset.
> ... but for Eastern European (for example - Russian) they are
> different. So, developers (porters) forget of that, and users (me)
> begun to moan :-)
When I first realized this issue, I decided not to fix it for 2 reasons:
1. smartctl output is often redirected to a file later examined by a GUI
(I frequently save smart info for my drives and compare the files with
WinMerge or KDiff3)
smartd output is always redirected, except in debug mode.
2. There is an easy workaround: Simply set the TZ environment variable
before running smartctl.
> I did not run smartd, but when i run smartctl i got unreadable garbage
> after time displayed.
> That garbage was to display "[...]" - "Moscow summer time".
Try "set TZ=MST-3MSD" and smartctl should display "MSD"
Note that it is probably not a good idea to set TZ globally. Some legacy
programs like old RCS or CVS releases are known to set wrong file times
if TZ is set.
> Seems it was the only non-English outut of program, but i expect there
> could be more of a kind.
No, smartd/smartctl itself only output plain ascii text, I don't think
there is more.
The garbage is a result of the tzname initialization in the MSC-Runtime.
I will probably fix this issue in the future (> 5.34).
If you are willing to test this, fell free to send me a private email.