On 25 September 2012 18:26, sebb <seb...@gmail.com> wrote: > On 25 September 2012 18:06, Honton, Charles <charles_hon...@intuit.com> wrote: >> Seems a little extreme solution. > > At least it allows the class to work with all Locales now, whereas > previously it would fail with those locales. > >> Exactly where does the FastDateParser fail with non-Gregorian calendars? > > You can try it and see - just comment out the code in FastDateParser > that creates the SimpleDateFormatStrategy. > > The main problem is that the formatted date output does not match the > generated regex. > > In the case of ja_JP_JP this is because the short form era > designations (M T S H) are not returned by the getEras() method. > I tried patching these in, but then the issue is that the eras are > quite complicated to evaluate, see [1] > > If you have a patch to fix that, please create a JIRA issue and attach it.
Fixed. Turns out that DateFormatSymbols#getEras() is only supposed to return AD/BC; one has to use Calendar#getDisplayNames() to fetch the LONG and SHORT era designators for th_TH and ja_JP_JP. Once the correct strings are used, parsing works fine. >> The parser should just be setting fields on a Calendar object which does the >> calculations. > > It does. > >> Are the fields being properly parsed? > > No, see above. > >> Is a proper Calendar object being created? > > Yes. > >> chas > > [1] > http://docs.oracle.com/javase/6/docs/technotes/guides/intl/calendar.doc.html --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
