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 127349 - Wrong date/time format
Wrong date/time format
Status: RESOLVED OBSOLETE
Product: gnome-panel
Classification: Other
Component: clock
2.11.x
Other FreeBSD
: Normal normal
: ---
Assigned To: Panel Maintainers
Panel Maintainers
Depends on: 69140
Blocks:
 
 
Reported: 2003-11-19 00:19 UTC by trabucant
Modified: 2020-11-06 20:26 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12



Description trabucant 2003-11-19 00:19:56 UTC
Clock-applet don't show numerical day and hour, but '-d' '-H'.


Month and minutes go right.


Thanks
Comment 1 Vincent Untz 2003-11-19 20:04:16 UTC
Christian: there's already been a bug about that, but I can't
reproduce. Do you know if the '-' thing in '%-d' is something standard
that works in every strftime implementation?
Comment 2 Christian Rose 2003-11-20 11:24:43 UTC
Don't know for sure. It might be something gnuish.
Comment 3 Malcolm Tredinnick 2003-12-01 11:24:30 UTC
It is amazing that -d works anywhere. It is completely non-standard
(in the sense of not in the single unix standard or the GNU manual
pages or anywhere else I can find).

The problem seems to be that some translators are adding it in (it is
not in the original source). For example, in da.po...

#: applets/clock/clock.c:819
msgid "%A, %B %d %Y"
msgstr "%A, %-d. %B %Y"

Somebody needs to get hold of the appropriate translators and shake
them about a bit until they use something standard (like %e or just
%d). Current offenders are da.po, hu.po, it.po and zh_CN.po. This is
just embarassing. :-(
Comment 4 Andras Timar 2003-12-01 12:36:57 UTC
This issue has been brought to my attention recently. The %-d breaks
things under FreeBSD. I'll fix these occurences in all hu.po files
that are affected soon. 

However in some GNOME projects the developers use a work-around for
the problem: they use a custom strftime from the eel library. In those
projects the translators do not have to avoid %-d.
Comment 5 Ole Laursen 2003-12-02 19:03:41 UTC
%e adds an extra space. That looks bad. It is really not the optimal
solution.
Comment 6 Ole Laursen 2003-12-02 19:04:49 UTC
Oops, sorry wrong bug. The comment should have gone to bug #122748.
Comment 7 Vincent Untz 2003-12-05 09:36:00 UTC
As Andras suggested, one solution would be to import the strftime
implementation from eel.
Mark: what do you think of that? IIRC, it's in eel-glib-extensions.c
or something like this. Is it ok to import this file for the clock applet?
Comment 8 Vincent Untz 2004-02-28 12:31:50 UTC
Mark: WONTFIX or use the eel code?
Comment 9 Mark McLoughlin 2004-02-28 13:23:51 UTC
Well, it really depends on how much people want to use %-d over %d or
%e.  Personally, I have trouble believing that a translation couldn't
suffice with one or the other.

That's what I'm interested in hearing about from translators.

Of course, it would be nice to have %-d support at some point and that
support should be implemented in glib, not code we copy and paste
around the place. Someone should open a glib bug requesting support
for this irrespective of what we do about this bug. Also, take not of
#69140 in which it looks like a glib strftime()-like function will be
added.

(So, leaning towards WONTFIX, unless someone can come up with a
convincing argument that %-d is vital for a particular locale)
Comment 10 Sebastien Bacher 2005-07-17 01:04:17 UTC
Mark, Vincent should this bug be closed?
Comment 11 Vincent Untz 2005-08-18 10:06:11 UTC
Danilo: will the new locale stuff help here too? Or do we need to have the
function in glib? Do you have interest in keeping this bug open? Many questions,
I know :-)
Comment 12 Danilo Segan 2005-08-18 13:23:50 UTC
Vincent: see bug #307121 -- it all started with the idea to be able to let users
customise their date and time (and other) formats which would affect their Gnome
desktop (and hopefully system) globally.  That will mean introducing new APIs
such as "glocale_format_time(GLOCALE_SHORT_TIME, datetime)" which would give you
a short time formatted according to user preferences (basically, you'd be able
to replace all you *_strftime calls).

On the bug: I think it should stay open, and clock applet will probably be one
of the first things to get the patch to work with the new library once it's
available (and we have Bruno, GNU gettext maintainer, working on our side, so
it's pretty likely that it's going to rock).
Comment 13 André Klapper 2020-11-06 20:26:08 UTC
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years.

If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/

Thank you for reporting this issue and we are sorry it could not be fixed.