Current GWT supports localized date/time formatting by providing predefined and localized patterns derived from Unicode CLDR data, accessible through DateFormat.get{Full,Long,Medium,Short}{Date,Time}Format(). However, these cover only a small range of the sort of formatting you would like to be able to perform. For example, DatePicker hard-codes format patterns "d" and "MMM yyyy" for its needs, yet that means they don't get properly localized. Another complication is there is no guidance on formatting a combined date/time value, as the order and connecting text differs between locales, and there is no guidance as to what the customary format for a locale is when you don't have specific needs.
CLDR has since added additional formats, named by the information that is provided by them. So for example, format yMMM maps to "MMM, y" in English, but "MMM y" in German and "MMMl y'x'G" in French. However, there are a lot of possible variations, and not all locales define the same set. ICU4J includes a DateTimePatternGenerator<http://icu-project.org/apiref/icu4j/index.html?com/ibm/icu/text/DateTimePatternGenerator.html>which takes a pattern skeleton and chooses/modifies the locale-specific pattern to best match what is requested. I propose improving GWT's date/time formatting abilities in the following ways: - create a new DateTimeFormatInfo interface to replace DateTimeFormatConstants - a default implementation DefaultDateTimeFormatInfo provides reasonable defaults and is useful for mocking - DateTimeFormatConstants would still be accepted by DateTimeFormatand would be wrapped by an adapter - it will clean up some issues with DateTimeFormatConstants that make it hard to extend, like having an array of date and time formats and defining return values of numeric fields as strings - localized implementations will have some set of common formats defined, processing the patterns as DateTimePatternGenerator would at the time the CLDR data is imported to GWT - DateTimeFormat will have new static getters for the additional common formats. The exact set is TBD, but something like: - DateTimeFormat getFormatDay() - DateTimeFormat.getFormatMonthDayAbbrev() - DateTimeFormat.getFormatYearMonthDayFull() - ... - This is chosen over having an enum passed into a getPredefinedFormat(PredefinedFormat) method for efficiency reasons, though perhaps improved enum optimizations will make that viable - add a new CustomDateTimeFormat interface which can be GWT.create'd to get localized patterns at compile time - example: public MyFormatters extends CustomDateTimeFormat { public static final MyFormatters INSTANCE = GWT.create(MyFormatters.class); @Pattern("yMMM") // or MMM, y etc, doesn't matter String yearMonthAbbrev(); @Pattern("M/d/y hh:mm:ss") // again, what matters is the included fields and their sizes, not the order or separator characters DateTimeFormat timestamp(); } dtf = DateTimeFormat.getInstance(MyFormatters.INSTANCE.yearMonthAbbrev()); dtf.format(date); dtf = MyFormatters.INSTANCE.timestamp(); ... - These patterns would still be processed at compile time and avoid runtime overhead - Returning DateTimeFormat will allow future optimizations that don't even parse the resulting pattern at runtime and reduce boilerplate code at the callsite, though may not be appropriate for all uses - extend Messages support to allow specifying a pattern skeleton rather than a pattern to be used directly, something like: - @DefaultMessage("Your order will ship on {0,localizedDate,M/d/y}") - This will be processed at compile time as well - Maybe we want to just rewrite all patterns supplied in date formats in Messages, but that would be a breaking change which would have to be carefully weighed Comments? -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors