DateTimeFormat now defines 4 date formats, 4 time formats, and 4 combined date/time formats (plus the ability to supply your own pattern, but then you are responsible for localizing it yourself). These formats don't cover all the possible use cases, such as a month/day or month/year format, or even more flexibility within some of the formats.
CLDR now defines additional formats (you can see some of them here<http://unicode.org/cldr/apps/survey?_=en&x=gregorian>, look under available_date_formats) which mostly address these limitations. There is a question about how to add them however. The current approach has a static method for each of the default formats, and continuing that trend would be painful, so I think we need to switch to something like DateTimeFormat formatter = DateTimeFormat.getPredefinedFormat(Format.FullDate) Another point of contention is what to do with the existing DateTimeConstants interface, which provides the constants used by DateTimeFormat to actually do the formatting. There are a few warts on it left over from when it was first created: - firstDayOfTheWeek() returns a string instead of an integer, so that means you have to parse the string at runtime and wouldn't detect an error until then, rather than doing it at compile time and detecting it then -- this also costs code size - likewise for weekendRange() -- it returns strings rather than integers with the problems listed above, and there really is no value to it being an array as you would never lookup by an index - there is no mechanism for describing how the date/time formats should be assembled together (currently we just assume the date goes first, followed by a single space, followed by the time, but that isn't correct in many locales) - date.time formats are split into separate arrays, and any existing implementations are only going to supply 4 patterns for each If we try and use the existing interface with no changes (to avoid making a breaking change), we can't fix these limitations. We could have each new format specify whether it was primarily a date or a time format and put it in the proper list (what happens when a combined format is added?), though it makes the lookup code a bit more complicated Existing implementations will only define 4 values of each, so that means the new formats would have to be emulated in some manner on top of them, and that emulation code would wind up being pulled into every client since this couldn't be known until runtime (the emulation code could be simple if we were willing to substitute one of the existing unmodified patterns, but then imaging getting even the short date in a calendar's day cell because the "d" format isn't defined. To me, it seems like it is worthwhile to go ahead and fix these limitations and make breaking changes to some apps. Those apps that would need changing will largely fall into two categories: 1. mock testing code that supplies a DateTimesConstant implementation We should do like we did for CurrencyData and provide a default implementation for such purposes, so in the future we can update it when the interface is changed. 2. code that consumes DateTimeConstants, typically to work around the limited formats or for special needs such as DatePicker In this case, I think those applications are likely to need changing anyway to take advantage of the new features and so it shouldn't be a big deal to break them, Finally, the changes are trivial so the effort required to adapt to the changes won't be an issue. The only real problem is that of a library wanting to support consecutive versions of GWT, but we seem to have enough changes that make that a problem already. So what do you think? Should we go out of our way to avoid a breaking change here, even if it means living with some limitations, or should we do it the way it should be done even if that means some code will have to be updated? -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
