This enhancement would add "System" date and time formats to the format menus. These would be implemented with the "%x" and "%X" formats, which display the date and time, respectively, in the locale's representation. Here are some examples which would otherwise require a custom date and/or time format. $ export LC_TIME=fr_FR.utf8 $ date +%x -d 'Jan 31 2008 13:00' 31.01.2008 $ date +%X -d 'Jan 31 2008 13:00' 13:00:00 $ export LC_TIME=zh_CN.utf8 $ date +%x -d 'Jan 31 2008 13:00' 2008年01月31日 $ date +%X -d 'Jan 31 2008 13:00' 13时00分00秒
Created attachment 1640 shell script to display "%x" and "%X" formats in all locales This shell script shows the effect of the "%x" and "%X" date/time formats in all locales. The script also shows the effect of the "E" modifier, which displays the alternative date/time representation. http://www.gnu.org/software/coreutils/manual/coreutils.html#date-invocation http://www.opengroup.org/onlinepubs/009695399/functions/strftime.html The alternative representation is not widely implemented, so it is not clear if the plugin should have menu items for it. Here is an example, however: $ export LC_TIME=ja_JP.utf8 $ date +%x -d 'Jan 31 2008 13:00' 2008年01月31日 $ date +%Ex -d 'Jan 31 2008 13:00' 平成20年01月31日
Another possible addition to the date formats would be the ISO standard date format implemented with the "%F" specifier. %F Equivalent to %Y - %m - %d (the ISO 8601:2000 standard date format). [ tm_year, tm_mon, tm_mday] http://www.opengroup.org/onlinepubs/009695399/functions/strftime.html http://en.wikipedia.org/wiki/ISO_8601 $ date +%F -d 'Jan 31 2008 13:00' 2008-01-31
(In reply to comment #2) > Another possible addition to the date formats would be the ISO standard date > format implemented with the "%F" specifier. No locale uses the first format in the date format menu. $ date +'%Y/%m/%d' -d 'Jan 31 2008 13:00' 2008/01/31 I believe that it could be replaced with "%F", although the locale-specific "System" date ("%x") would probably be a better choice for the first, default format.
Created attachment 1641 add "System" and "%F" formats to property menus This patch adds a "System" format to the date and time property menus and makes them the default. It also replaces one of the date formats with "%F". The major internal change is a redesign of the menu setup data structure to explicitly separate the date/time format from the menu text. This is in preparation for working on bug 4097. This patch also removes all tabs from datetime-dialog.c. The patch is against trunk.
Created attachment 1642 adds fix to avoid activating separator with custom format "---" This updated patch adds a fix to avoid activating the menu separator when the custom format is "---". This update fixes bug 4115 in addition to adding the previously described enhancements.
Re Comment #5 and Attachment #1642 : Firstly, thanks a lot for your interest in datetime and for these bugs and patches. It's really nice to have someone help out :D I've started reviewing the patch you have attached (#1642). Here are my initial comments: * The whitespace fixes add too much noise to the patch. I independently fixed the whitespace in r4848. * Needs a set of braces around each dt_format_t pair in the dt_format_t arrays. * I didn't look at this very closely, but in the dt_format_t arrays: why use NULL to indicate there is no format entry, but "" to indicate there is no text? * It's important to see an example of the date/time in the dropdown. The word "System" isn't very useful on its own. Once the above has been addressed, I'll review it a little more closely and commit it in svn. Thanks again!
(In reply to comment #6) > Re Comment #5 and Attachment #1642 : > > Firstly, thanks a lot for your interest in datetime and for these bugs and > patches. It's really nice to have someone help out :D Thanks for your comments. > I've started reviewing the patch you have attached (#1642). Here are my initial > comments: > > * The whitespace fixes add too much noise to the patch. I independently fixed > the whitespace in r4848. Thanks for fixing the whitespace. The tabs were driving me nuts. The bugzilla patch viewer is very convenient, but it doesn't display whitespace diffs as clearly as "meld" (which AFAICT cannot display patch files). > * Needs a set of braces around each dt_format_t pair in the dt_format_t arrays. OK. > * I didn't look at this very closely, but in the dt_format_t arrays: why use > NULL to indicate there is no format entry, but "" to indicate there is no > text? My original idea was to dynamically allocate the custom formats in the arrays. That won't work because the plugin is internal, so multiple instances of the plugin cannot share those custom fields. Further, the custom formats are state info the should go in the t_datetime structure. > * It's important to see an example of the date/time in the dropdown. The word > "System" isn't very useful on its own. Yeah, I'm not satisfied with "System" either. The problem is that simply converting the example time using "%x" will result in *two* menu items that look identical in either the en_US or the en_GB locales. That will leave users wondering what the difference is. $ date +'%x' -d 'dec 31, 1999 23:59:59' 12/31/1999 $ date +'%m/%d/%Y' -d 'dec 31, 1999 23:59:59' 12/31/1999 The standard formats are a logical selection, but they seem to be en_US and en_GB locale-centric. So, the rationale for adding these formats ("%x" and "%X") is to provide locale-specific defaults. Maybe the wording could be "Locale default (12/31/1999)". BTW, there is precedent for use of the the word "Default" in the Xfce settings. The Xfce Window Manager settings dialog uses it in the Style and Keyboard menus. The Display Resolution and Keyboard Settings dialogs use it too. > Once the above has been addressed, I'll review it a little more closely and > commit it in svn. Thanks again!
(In reply to comment #7) > Maybe the wording could be "Locale default (12/31/1999)". Another possibility -- more consistent with the other menu items: "12/31/1999 (from locale)" The calendar section of the datetime properties dialog already uses "locale" in an explanatory context. Have you ever seen it used in a settings or properties dialog?
(In response to comment #7:) > Yeah, I'm not satisfied with "System" either. The problem is that simply > converting the example time using "%x" will result in *two* menu items that > look identical in either the en_US or the en_GB locales. That will leave users > wondering what the difference is. We should try to avoid any duplicates in the dropdowns, even if it is (relatively) computationally expensive to do so. (In response to comment #8:) > The calendar section of the datetime properties dialog already uses "locale" in > an explanatory context. Have you ever seen it used in a settings or properties > dialog? No, I don't think I have. I'm really considering dropping that entire note - I think it'll waste people's time or confuse them rather than help anyone.
(In reply to comment #9) > We should try to avoid any duplicates in the dropdowns, even if it is > (relatively) computationally expensive to do so. Yes, I agree, and hadn't thought of automatically removing dupes. Since we would know which formats could result in dupes, the removal could probably be optimized some. Here is a suggestion from a friend -- the format strings are just text, so they could be "translated" in the po files. This would allow more localization than the formats provided by the locale. There isn't really enough info from users concerning the usefulness of the formats in the menus, so I am thinking of withdrawing my patch for this enhancement and resubmitting the essentials as a fix for bug 4115. How does that sound? > (In response to comment #8:) > > The calendar section of the datetime properties dialog already uses "locale" in > > an explanatory context. Have you ever seen it used in a settings or properties > > dialog? > No, I don't think I have. I'm really considering dropping that entire note - I > think it'll waste people's time or confuse them rather than help anyone. I have opened bug 4123.
In response to Comment #10: > Here is a suggestion from a friend -- the format strings are just text, so they > could be "translated" in the po files. This would allow more localization than > the formats provided by the locale. I don't think that's the right way to go. It might work well if there was only one format, but with several - perhaps a variable amount of - formats, I don't see it working well. > There isn't really enough info from users concerning the usefulness of the > formats in the menus, so I am thinking of withdrawing my patch for this > enhancement and resubmitting the essentials as a fix for bug 4115. How does > that sound? I need to think about this some more...then I'll reply again.
Let's not do anything (more) about the default formats until we get some feedback. The nice thing is that it's easy to enter in a custom format.