GNOME Bugzilla – Bug 658061
g_date_time_format(): Add support for missing identifiers
Last modified: 2011-09-03 01:22:31 UTC
Currently g_date_time_format() only support a subset of the strftime() format language.
Created attachment 195487 [details] [review] support %V
Created attachment 195494 [details] [review] support %c
Created attachment 195499 [details] [review] support %C
Created attachment 195500 [details] [review] support %w
step 1: find a widely-respected standard that claims to specify the behaviour of strftime() step 2: copy it exactly
Let's say C99. It's what I would consider to be an absolute baseline. All of your patches (%V, %c, %C, %w) are specified in C99, so we should support those. It also specifies: %D - is equivalent to ‘‘%m/%d/%y’’ %g - is replaced by the last 2 digits of the week-based year (see below) as a decimal number (00−99) %G - is replaced by the week-based year (see below) as a decimal number (e.g., 1997) %U - is replaced by the week number of the year (the first Sunday as the first day of week 1) as a decimal number (00−53) It also specifies the 'E' modifier that we lack for "alterrnative" representations. I'm not sure that we have a reasonable way of supporting this; probably we should just accept and ignore it (for now). vs. C99, we support the extra conversions: %k - hour from ' 0' to '23' (ie: space instead of '0' as with %H) %l - hour from ' 1' to '12' (ie: space instead of '0' as with %I) %s - seconds since the epoch %P - "am" or "pm" (ie: lowercase instead of "AM" or "PM" for %p) %N - microseconds %k, %l and %s were originated by Olson's timezone package and are now included in glibc. %P is a GNU extension. Although these are not standardised, it's probably reasonable to continue to support them since their use in glibc means that future versions of the C standard are likely to be careful about stomping them. %N is totally unspecified anywhere and is not supported in glibc. This concerns me, since it's possible that some future version of the C standard might introduce 'N' to mean something else at which point we'd be completely stuck.
Comment on attachment 195500 [details] [review] support %w Looks right.
Review of attachment 195499 [details] [review]: minor change, then good to commit ::: glib/gdatetime.c @@ +2160,3 @@ + * <literal>%%C</literal>: + * </term><listitem><simpara> + * The century number (year/100) as a 2-digit integer add "(00-99)" here to clarify that it gets padded with a zero
Review of attachment 195494 [details] [review]: please commit after making the changes ::: glib/gdatetime.c @@ +203,3 @@ +/* Translators: this is the preferred format for expressing the date and the time */ +#define PREFERRED_DATE_TIME_FMT C_("GDateTime", "%m/%d/%y %H:%M:%S") the untranslated string should be "%a %b %e %H:%M:%S %Y". that's what nl_langinfo(D_T_FMT) returns in the C locale. @@ +2155,3 @@ + * <literal>%%c</literal>: + * </term><listitem><simpara> + * the preferred date and time representation for the current locale. remove the period from the end of this sentence for consistency
Review of attachment 195487 [details] [review]: good to commit after changes ::: glib/gdatetime.c @@ +2265,3 @@ + * <literal>%%V</literal>: + * </term><listitem><simpara> + * The ISO 8601 week number of the current year as a decimal number, nitpick: lowercase "the" at the start. @@ +2518,3 @@ break; + case 'V': + get_numeric_format (fmt, sizeof(fmt), alt_digits, 0, 0); C99 says %V should always be zero-padded
I don't feel bad about removing %N because, as it stands, it's actually somewhat useless. You might think about doing something like "%S.%N" as a format, but that wouldn't work anyway: - "." is not localised - the format used for %N does not pad with zeros, so instead of "41.000232", you'd get "41.232", which is quite broken.
Created attachment 195511 [details] [review] g_date_time_format: drop %N format %N is not specified in any standard document, but we use it to display %the number of microseconds. The fact that our our current implementation of it is nearly useless (since it does not zero-pad) coupled with the high chance that a future version of the C standard may specify it with another meaning means that we should drop it.
Created attachment 195513 [details] [review] g_date_time_format: support %D %D represents the date in mm/dd/yy format.
Review of attachment 195511 [details] [review]: Hmm, I'm not sure we can do that - this was released in GLib 2.26. A Google Code Search doesn't reveal any users, but... You could drop it from the docs or just mark it as deprecated?
Review of attachment 195513 [details] [review]: Looks good to me, and thanks for the C99 analysis.
Created attachment 195520 [details] [review] g_date_time_format: support %D Had a mistake in the format string for this one.
Created attachment 195521 [details] [review] g_date_time_format: support %g and %G These are the 2-digit and 4-digit ISO week-numbering years.
Review of attachment 195520 [details] [review]: Actually...this reveals that we should probably have some tests.
I'm going to add a mega-test once I commit all of these.
Created attachment 195543 [details] [review] g_date_time_format: support %V %V represents the ISO 8601 week number of the current year as a decimal number, range 01 to 53, where week 1 is the first week that has at least 4 days in the new year
Created attachment 195544 [details] [review] g_date_time_format: support %c %c represents the preferred date and time representation for the current locale.
Created attachment 195545 [details] [review] g_date_time_format: support %C %C represents the century number (year/100) as a 2-digit integer
Attachment 195511 [details] pushed as 034952e - g_date_time_format: drop %N format Attachment 195521 [details] pushed as a1b665c - g_date_time_format: support %g and %G Attachment 195543 [details] pushed as b42d154 - g_date_time_format: support %V Attachment 195544 [details] pushed as 6f80dc6 - g_date_time_format: support %c Attachment 195545 [details] pushed as e975b5b - g_date_time_format: support %C I'm going to hold off on pushing %D and %U for now since they're ugly.
In addition to not pushing %D and %U, I ripped out our broken implementation of %W (which is just like %U). I added some tests and clarified the docs as well. If someone wants to come along and add %D and %U and (a working) %W then they can do that, but I can't be bothered to implement them myself.
Review of attachment 195520 [details] [review]: Adding a comment just incase anybody comes along and tries to use this. ::: glib/gdatetime.c @@ +2408,3 @@ + g_date_time_get_month (datetime), + g_date_time_get_day_of_month (datetime), + g_date_time_get_year (datetime)); this is broken. get_year() needs to be % by 100.