Custom time format in datetime applet cannot handle some format specifiers

%W works in my format, but %U and %V don't. They blank the whole datetime display, although the required space is still reserved.

%a %d-%m-%Y (Wk%V) %H:%M:%S
displays nothing, but is equally wide as
%a %d-%m-%Y (Wk%W) %H:%M:%S
which displays the correct date and time on my system (but I need the other week number).

%V %V %V is blank and three times as wide as just %V

Bug #730476:
"In the code, measuring is done using the strftime function while the rendering uses g_date_time_format. It seems these two functions use different parts of the locale settings."

g_date_time_format does not support %V or %U:
http://developer.gnome.org/glib/2.28/glib-GDateTime.html#g-date-time-format

Is this an upstream bug, or should the indicator-datetime be using strftime instead (which I thought it did)?

Yeah, we are using the g_date_time_format() function from glib.
The format strings understood by this function are a subset of the strftime() format language, see http://developer.gnome.org/glib/2.28/glib-GDateTime.html#g-date-time-format.

Feel free to open a bug upstream to add the time specifiers you need

FYI %T support was added in Glib recently and will be available in Glib 2.30 (oneiric)

If it is impossible or undesirable to use strftime() instead of g_date_time_format() in the rendering, then this bug is a documentation issue. The summary for the custom-time-format field in the dconf-editor clearly states that strftime() is used.
"Summary: The format string passed to strftime"

The description should be revised as well:
"Description: The format of the time and/or date that is visible on the panel when using
     the indicator. For most users this will be a set of predefined values as
     determined by the configuration utility, but advanced users can change it
     to anything strftime can accept. Look at the man page on strftime for
     more information."

But I hope it is possible to change the indicator-datetime code to use strftime(), simply because that function does the job already and no upstream fix would be required.

#5: +1.

Although as far as I'm concerned (as a user!) this is a regression. A regression of the "I want to be able to tell time by the same format as I did in the last version of Ubuntu" functionality. It doesn't seem fair that it would be enough to say it's just a documentation issue. That would be like upgrading from Office 2003 to Office 2007 and all of a sudden Word doesn't feature a WYSIWYG interface anymore, but wait, it clearly states in the manual on the CD/DVD that this is the case, so that means it's okay?

Clearly most users would be like "wtf? No." :)

@victorz:
That (Gnome?) version allowed some HTML tags as well, but I need them less than the ISO 8601 week number, which is the standard in my country (The Netherlands).

@rahuijts: Same here. I didn't use HTML either, and the ISO week number is standard here in Sweden as well. This is a localization/internationalization issue (whichever one is more appropriate) in my opinion. It's very specific but nonetheless.

The problem is that it's not generally possible to ask the libc to deal with any timezones other than local and utc
So lets fix this in the proper way and fix the glib function to support more formats.

Support for all the remaining strftime() specifiers was added upstream

This bug was fixed in the package indicator-datetime - 0.2.95-0ubuntu1

---------------
indicator-datetime (0.2.95-0ubuntu1) oneiric; urgency=low

  [ Ted Gould ]
  * New upstream release.
    * Set default timezone on events without (LP: #837359)
    * Update docs to specify correct custom formats (LP: #775113)
    * Remove add event when using greeter (LP: #836521)
    * Fix gettext domain for builder files (LP: #845473)
    * Update date correctly when opening menu (LP: #793450)

  [ Didier Roche ]
  * debian/control:
    - bump the libglib build-dep
 -- Ted Gould <email address hidden> Thu, 15 Sep 2011 10:45:57 -0500