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 131145 - eel_strdup_strftime non-Gregorian year
eel_strdup_strftime non-Gregorian year
Status: RESOLVED FIXED
Product: eel
Classification: Deprecated
Component: general
1.0.x
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-01-11 10:06 UTC by Ross Golder
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
%E not supported in eel_strdup_strftime (523 bytes, text/plain)
2004-01-11 18:37 UTC, Paisa Seeluangsawat 		Details

Description Ross Golder 2004-01-11 10:06:12 UTC 
Users of locales that do not use the Gregorian calendar (such as Thailand,
which uses the Buddhist calendar) cannot obtain the year localised when
using eel_strdup_strftime (e.g. Nautilus). ANSI C does not appear to allow
for it. (e.g. 2000AD == 2543BC)

It appears there is a non-standard extension, '%Ey' that can be used, but
eel_strdup_strftime produces a warning and passes the '%Ey' through verbose.

What can we do to obtain the year localised?
Comment 1 Roozbeh Pournader 2004-01-11 14:41:58 UTC 
Ross, would you please provide exact steps to reproduce?
Comment 2 Paisa Seeluangsawat 2004-01-11 18:37:28 UTC 
Created attachment 23235 [details]
%E not supported in eel_strdup_strftime
Comment 3 Paisa Seeluangsawat 2004-01-11 19:03:22 UTC 
%E is documented in Single Unix spec,

  http://www.opengroup.org/onlinepubs/007908799/xcu/date.html

nautilus/libnautilus-private/nautilus-file.c, contains many date/time
specifiers destined for eel_strdup_strftime.  While localizing to some
languages (e.g. Thai, Japanese), using %Ey instead of %Y can give a
year format that local users are more accustom to.
Comment 4 Ross Golder 2004-02-16 07:24:36 UTC 
This seems to have been resolved now. Thankyou to whoever fixed it!