Very cool, Thanks for a more elegant solution. chas
On 9/26/12 11:14 AM, "sebb" <seb...@gmail.com> wrote: >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.h >>tml > >--------------------------------------------------------------------- >To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
