right now, we are using two hard-coded formats that we defined for rendering date-time values for Japanese, and for non-Japanese locales: - "yyyy-MM-dd, HH:mm" for Japanese. - "yyyy-MMM-dd, HH:mm" for all other locales. we should not write and maintain our own logic for manipulating date-time formats per locale - we should use a predefined date-time format that will take care of the manipulation for us. following Alexander's suggestion in https://gerrit.ovirt.org/#/c/42875/: I recommend going over all pre-defined date-time formats in [1], looking for the one that renders "yyyy-MMM-dd, HH:mm" (or something very close to it) in the 'en-US' locale, and go with that format for all locales - and, IIUC, the format will adjust itself properly for every locale. [1] http://www.gwtproject.org/javadoc/latest/com/google/gwt/i18n/client/DateTimeFormat.PredefinedFormat.html
*** Bug 1247777 has been marked as a duplicate of this bug. ***
Just so we have an informed opinion, I printed out all the formats for today: ISO_8601 yyyy-MM-dd'T'HH:mm:ss.SSSZZZ 2015-07-30T19:24:04.498+00:00 RFC_2822 EEE, d MMM yyyy HH:mm:ss Z Thu, 30 Jul 2015 19:24:04 +0000 DATE_FULL EEEE, MMMM d, y Thursday, July 30, 2015 DATE_LONG MMMM d, y July 30, 2015 DATE_MEDIUM MMM d, y Jul 30, 2015 DATE_SHORT M/d/yy 7/30/15 TIME_FULL h:mm:ss a zzzz 7:24:04 PM UTC TIME_LONG h:mm:ss a z 7:24:04 PM UTC TIME_MEDIUM h:mm:ss a 7:24:04 PM TIME_SHORT h:mm a 7:24 PM DATE_TIME_FULL EEEE, MMMM d, y h:mm:ss a zzzz Thursday, July 30, 2015 7:24:04 PM UTC DATE_TIME_LONG MMMM d, y h:mm:ss a z July 30, 2015 7:24:04 PM UTC DATE_TIME_MEDIUM MMM d, y h:mm:ss a Jul 30, 2015 7:24:04 PM >DATE_TIME_SHORT M/d/yy h:mm a 7/30/15 7:24 PM< DAY d 30 HOUR_MINUTE h:mm a 7:24 PM HOUR_MINUTE_SECOND h:mm:ss a 7:24:04 PM HOUR24_MINUTE HH:mm 19:24 HOUR24_MINUTE_SECOND HH:mm:ss 19:24:04 MINUTE_SECOND mm:ss 24:04 MONTH LLLL July MONTH_ABBR LLL Jul MONTH_ABBR_DAY MMM d Jul 30 MONTH_DAY MMMM d July 30 MONTH_NUM_DAY M/d 7/30 MONTH_WEEKDAY_DAY EEEE, MMMM d Thursday, July 30 YEAR y 2015 YEAR_MONTH MMMM y July 2015 YEAR_MONTH_ABBR MMM y Jul 2015 >YEAR_MONTH_ABBR_DAY MMM d, y Jul 30, 2015< YEAR_MONTH_DAY MMMM d, y July 30, 2015 YEAR_MONTH_NUM M/y 7/2015 YEAR_MONTH_NUM_DAY M/d/y 7/30/2015 YEAR_MONTH_WEEKDAY_DAY EEE, MMM d, y Thu, Jul 30, 2015 YEAR_QUARTER QQQQ y 3rd quarter 2015 YEAR_QUARTER_ABBR Q y Q3 2015 This is the current format: yyyy-MMM-dddd [HH:mm:[ss]] With the time and the seconds being optional based on passed in flags. Looking at the above I would say 1. If just year/month/day, use YEAR_MONTH_ABBR_DAY 2. If year/month/day and hours/minutes, use DATE_TIME_SHORT 3. If everything use DATE_TIME_MEDIUM That doesn't match 100%, but it is fairly close. @Einav, what do you think?
I have a few thoughts -- 1. Choosing a built-in Java format should make that format be nice in all locales, if I understand correctly. YEAR_MONTH_ABBR_DAY could be a good choice. That cleans up our code for us a bit. * Can we verify that whatever format we choose looks good in our typical locales / translations -- Japanese, Chinese, Spanish, English (US), etc? 2. Can we have a default and make in configurable? (Why not let a user choose his pref? *) [*] may be very useful when we do the CSV export from grids feature. People will care about those date formats!
(In reply to Alexander Wels from comment #2) > This is the current format: > yyyy-MMM-dddd [HH:mm:[ss]] > > With the time and the seconds being optional based on passed in flags. > Looking at the above I would say > > 1. If just year/month/day, use YEAR_MONTH_ABBR_DAY > 2. If year/month/day and hours/minutes, use DATE_TIME_SHORT > 3. If everything use DATE_TIME_MEDIUM > > That doesn't match 100%, but it is fairly close. > > @Einav, > what do you think? agreed. [it's somewhat frustrating that there is no predefined format with "MMM d, y" as the month/day/year portion *and* with a time portion that contains only hours and minutes...] (In reply to Greg Sheremeta from comment #3) > I have a few thoughts -- > > 1. Choosing a built-in Java format should make that format be nice in all > locales, if I understand correctly. YEAR_MONTH_ABBR_DAY could be a good > choice. That cleans up our code for us a bit. yes. as Alexander mentioned - we should use this format for dates that were set to be displayed without the time portion (i.e. without hours/minutes/seconds). BTW - just curious: - any idea what is the difference between YEAR_MONTH_ABBR_DAY and DATE_MEDIUM? - where in the GUI do we display date only (i.e. without the time portion) or date/time with the seconds portion? all I could find are instances of "yyyy-MMM-dddd, HH:mm" (e.g. "2015-Jul-30, 16:24") > > * Can we verify that whatever format we choose looks good in our typical > locales / translations -- Japanese, Chinese, Spanish, English (US), > etc? yes - when creating the patch, need to take screen-shots of the displayed date/time in all of our supported locales and include links to these the screen-shots in gerrit. we can even send those over to the localization team for verification. > > 2. Can we have a default and make in configurable? (Why not let a user > choose his pref? *) > > [*] may be very useful when we do the CSV export from grids feature. People > will care about those date formats! that's a good idea - but let's keep it for a separate BZ/patch for now, as we'll need to think about how to allow setting this preference in the GUI.
> where in the GUI do we display date only (i.e. without the time portion) New errata screens have an "issue date" with no time. > date/time with the seconds portion? Gluster screens (time sensitive rebalancing ops, etc.)
> BTW - just curious: > > - any idea what is the difference between YEAR_MONTH_ABBR_DAY and > DATE_MEDIUM? Not quite sure, they look identical to me. > [it's somewhat frustrating that there is no predefined format with "MMM d, y" as the month/day/year portion *and* with a time portion that contains only hours and minutes...] We could concatenate DATE_MEDIUM with HOUR_MINUTE or HOUR24_MINUTE, assuming that everywhere date is followed by time. if we don't want to make that assumption (not 100% sure I want to do that), then we are stuck with DATE_TIME_SHORT.
@Einav, The feedback I am getting from the Translators is that they don't like the DATE_TIME_SHORT for the cases I have shown them. They want basically DATE_MEDIUM + TIME_SHORT. As I said above I can probably do the the concatenation of the two, but not 100% sure if that is always correct in all locales. What would you like me to do?
(In reply to Alexander Wels from comment #7) > @Einav, > > The feedback I am getting from the Translators is that they don't like the > DATE_TIME_SHORT for the cases I have shown them. They want basically > DATE_MEDIUM + TIME_SHORT. As I said above I can probably do the the > concatenation of the two, but not 100% sure if that is always correct in all > locales. > > What would you like me to do? Thanks for checking with them, Alexander. I understand that they don't like the DATE_TIME_SHORT - I don't like it much either, but we are looking for something with a legal format, not necessarily a likeable format. If they want DATE_MEDIUM + TIME_SHORT - we/they can open a GWT issue requesting a DATE_MEDIUM + TIME_SHORT pre-defined format, and/or adjusting the DATE_TIME_SHORT format specifically for Korean, but we don't know if it will be addressed, and even if so - for which GWT version it will be address and if/when we would be consuming that GWT version. To my understanding, the current date-time display is simply illegal, i.e. contains some string combinations/misplaced characters that just don't make sense, per bug 1247896. So just need to understand whether the new suggested DATE_TIME_SHORT format is legal. From their response on bug 1247896, it is implied that the format is legal, they just prefer that for Korean - the year will be fully displayed (2015) rather than abbreviated (15). We cannot do that. Let's keep it as is, please make sure to answer the question on bug 1247896 and explain that you are limited to the GWT pre-defined date-time formats constraints and there is nothing that you can do other than report this issue to GWT.
> To my understanding, the current date-time display is simply illegal, i.e. > contains some string combinations/misplaced characters that just don't make > sense, per bug 1247896. Well the problem is that current the format pattern is fixed to a particular pattern that in certain locales leads to an invalid date. per the mentioned bug. To solve this, we are using the predefined constants which adjust the pattern according to the selected locale. So doing the concatenation of two predefined constants, will mean that the concatenation will still change according to the selected locale. My only concern is that the concatenation is constant, so if we have a right to left locale the order might be wrong, or something else we haven't thought of. I am sure for our current available locales it will work is legal, but can't guarantee future locales.
Verified on 3.6.0-19 Time format is different/correct for every language/locale
Since oVirt 3.6.0 has been released, moving from verified to closed current release.