After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 548947 - In non-UTF-8 locale date is not displayed correctly.
In non-UTF-8 locale date is not displayed correctly.
Status: RESOLVED FIXED
Product: gnome-commander
Classification: Other
Component: application
1.2.x
Other All
: Normal normal
: 1.2.8
Assigned To: epiotr
epiotr
Depends on:
Blocks:
 
 
Reported: 2008-08-22 04:35 UTC by agc-tester
Modified: 2008-09-24 17:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to handle non-UTF-8 encoding date (849 bytes, patch)
2008-09-04 07:14 UTC, agc-tester
none Details | Review
patch to handle non-UTF8 encoding date, revised (570 bytes, patch)
2008-09-04 21:46 UTC, epiotr
none Details | Review
[Settings] -> [Option] -> [Format] dialog tab (20.11 KB, image/png)
2008-09-05 02:11 UTC, Takao Fujiwara
  Details
patch to handle non-UTF8 encoding date, rev. 3 (4.32 KB, patch)
2008-09-08 20:44 UTC, epiotr
none Details | Review
Patch for src/gnome-cmd-options-dialog.cc, src/utils.cc (1.67 KB, patch)
2008-09-10 04:14 UTC, Takao Fujiwara
none Details | Review

Description agc-tester 2008-08-22 04:35:40 UTC
Please describe the problem:
When a user login to a non-UTF-8 locale, and launch GNOME Commander(don't update folders under $HOME to non-UTF-8 encoding names when login), "day" and "month" in displayed time of files are garbage characters.

Steps to reproduce:
1. Login to GNOME with a non-UTF-8 locale, such as zh_CN.GBK
2. Launch gnome-commander
3. Check the date of files displayed


Actual results:
"day" and "month" in displayed time of files are garbage characters.

Expected results:
Localized "day" and "month" are displayed.

Does this happen every time?
Yes.

Other information:
utils.cc::time2string() needs to be revised.
Comment 1 agc-tester 2008-09-04 07:14:12 UTC
Created attachment 117982 [details] [review]
patch to handle non-UTF-8 encoding date
Comment 2 epiotr 2008-09-04 21:46:02 UTC
Created attachment 118056 [details] [review]
patch to handle non-UTF8 encoding date, revised

As for time2string() is used very intensely by gcmd, I'd rather keep expensive calls to g_locale_to_utf8() as low as possible... Why to convert date_format from locale to UTF8? IMHO date_format is pure ASCII (like %X or %Y.%m.%d %T), so it doesn't need any conversion. 

I've attached the revised patch - could you, please, verify if it works for you?
Comment 3 Takao Fujiwara 2008-09-05 02:11:28 UTC
Created attachment 118067 [details]
[Settings] -> [Option] -> [Format] dialog tab

> Why to convert date_format from locale to UTF8? 

The format can be customized in GUI. I think it needs to be UTF-8 instead of ASCII.
Please find the attachment.
Comment 4 epiotr 2008-09-08 20:44:24 UTC
Created attachment 118327 [details] [review]
patch to handle non-UTF8 encoding date, rev. 3

Right, I see it now...

Please verify the attached patch if it is working for you. gcmd stores internally date_format in locale format now, converting it from/to UTF8 when appropriate (loading/saving cfg file and editing in GUI). This way we can still save one call to g_locale_to_utf8().

Please do test.
Comment 5 Takao Fujiwara 2008-09-10 04:14:05 UTC
Created attachment 118410 [details] [review]
Patch for src/gnome-cmd-options-dialog.cc, src/utils.cc

> Created an attachment (id=118327) [edit]

Unfortunately I got garbaged strings with your patch on the option GUI dialog.

+    gnome_cmd_data_set_date_format (g_locale_from_utf8 (format, -1, NULL, NULL, NULL));

I'm not sure why you need the locale value instead of UTF-8. However I'd like to recommend to use UTF-8 as the internal encoding and use the locale encoding in case we use the native APIs or output/input user files.

How about the attached patch?
It works fine with me.
Comment 6 epiotr 2008-09-24 17:40:07 UTC
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.