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
