cahuja comments

Results 7 comments of


                                            cahuja

Month suffixes in dateFormatter double in japanese

Looking at your CLDR ticket, would it make sense to add this missing pattern - "MMMM": "M月" to dateTimeFormats instead of adding complete skeletons?

Mismatch between Globalize and other libraries when dealing with missing skeletons as per TR-35 with dealing with combining date and time patterns

A similar issue happens for pt-PT as well. The spec ([TR-35](http://www.unicode.org/reports/tr35/tr35-dates.html#Missing_Skeleton_Fields)) directs us to use the dateFormatLength full when using the pattern "yMMMMdjm" > Combine the patterns for the two...

Mismatch between Globalize and other libraries when dealing with missing skeletons as per TR-35 with dealing with combining date and time patterns

Also, all my tests are on CLDR 28

Mismatch between Globalize and other libraries when dealing with missing skeletons as per TR-35 with dealing with combining date and time patterns

This also happens for es-CL. That is enough information to suppose it is an issue for all locales.

Mismatch between Globalize and other libraries when dealing with missing skeletons as per TR-35 with dealing with combining date and time patterns

Another example of this helps narrow this down as an ICU4j bug is as follows - In the locale "fr-BE", for pattern "yyMdjm", we are combining the date and time...

Matching to predefined formats

I think this should be another CLDR bug.

Unexpected matching in Polish format in Globalize

A workaround that worked was to explicitly provide yLLL as a format so that I avoid the matching code altogether and concat this with the CLDR data.