commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruno P. Kinoshita (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LANG-1328) FastDateFormat does not support 'EEE' and 'MMM' abbreviations for PT_pt
Date Sat, 06 May 2017 02:50:04 GMT

    [ https://issues.apache.org/jira/browse/LANG-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15999233#comment-15999233
] 

Bruno P. Kinoshita commented on LANG-1328:
------------------------------------------

Hello,

Downloaded Android Studio (latest version), added Commons Lang 3.5 via Gradle, added your
code minus the Android specific line, and then put a breakpoint to see what's happening.

In my case, I'm getting for pt_PT domingo for the EEE mask. Same code in Oracle JVM gives
me dom for EEE. I'm guessing the extra R that appears for you is a typo? Or are you really
seeing Dor and Dormingo? Dormingo does not exist in Portuguese (except as a slang, recently
created).

Debugging, I could see that my Oracle JDK was using a ResourceBundle to load the Locale specific
strings, while in Android, it was using ICU (import libcore.icu.LocaleData). Attaching some
images from my IDE's with breakpoints around where I think the code differs.

I tried reproducing the issue with Oracle JDK + ICU here https://github.com/kinow/commons-sandbox/blob/master/src/main/java/br/eti/kinoshita/commons/LangDateTests.java,
but I still get Dom for Oracle JDK, and dom with IBM ICU4J (tried recent versions, and the
oldest I tried was 4.0.1).

I wonder if the following excerpt from Google's libcore helps:

{quote}
From: https://android.googlesource.com/platform/libcore/+/5d930ca/luni/src/main/java/java/util/Locale.java

 * 
<p>Note that locale data is not necessarily available for any of the locales pre-defined
as
 * constants in this class except for en_US, which is the only locale Java guarantees is always
 * available.
 *
 * <p>It is also a mistake to assume that all devices have the same locales available.
 * A device sold in the US will almost certainly support en_US and es_US, but not necessarily
 * any locales with the same language but different countries (such as en_GB or es_ES),
 * nor any locales for other languages (such as de_DE). The opposite may well be true for
a device
 * sold in Europe.

Versions of ICU:

 * <p>Here are the versions of ICU (and the corresponding CLDR and Unicode versions)
used in
 * various Android releases:
 * <table BORDER="1" WIDTH="100%" CELLPADDING="3" CELLSPACING="0" SUMMARY="">
 * <tr><td>Android 1.5 (Cupcake)/Android 1.6 (Donut)/Android 2.0 (Eclair)</td>
 *     <td>ICU 3.8</td>
 *     <td><a href="http://cldr.unicode.org/index/downloads/cldr-1-5">CLDR 1.5</a></td>
 *     <td><a href="http://www.unicode.org/versions/Unicode5.0.0/">Unicode 5.0</a></td></tr>
 * <tr><td>Android 2.2 (Froyo)</td>
 *     <td>ICU 4.2</td>
 *     <td><a href="http://cldr.unicode.org/index/downloads/cldr-1-7">CLDR 1.7</a></td>
 *     <td><a href="http://www.unicode.org/versions/Unicode5.1.0/">Unicode 5.1</a></td></tr>
 * <tr><td>Android 2.3 (Gingerbread)/Android 3.0 (Honeycomb)</td>
 *     <td>ICU 4.4</td>
 *     <td><a href="http://cldr.unicode.org/index/downloads/cldr-1-8">CLDR 1.8</a></td>
 *     <td><a href="http://www.unicode.org/versions/Unicode5.2.0/">Unicode 5.2</a></td></tr>
 * <tr><td>Android 4.0 (Ice Cream Sandwich)</td>
 *     <td><a href="http://site.icu-project.org/download/46">ICU 4.6</a></td>
 *     <td><a href="http://cldr.unicode.org/index/downloads/cldr-1-9">CLDR 1.9</a></td>
 *     <td><a href="http://www.unicode.org/versions/Unicode6.0.0/">Unicode 6.0</a></td></tr>
 * <tr><td>Android 4.1 (Jelly Bean)</td>
 *     <td><a href="http://site.icu-project.org/download/48">ICU 4.8</a></td>
 *     <td><a href="http://cldr.unicode.org/index/downloads/cldr-2-0">CLDR 2.0</a></td>
 *     <td><a href="http://www.unicode.org/versions/Unicode6.0.0/">Unicode 6.0</a></td></tr>
 * <tr><td>Android 4.3 (Jelly Bean MR2)</td>
 *     <td><a href="http://site.icu-project.org/download/50">ICU 50</a></td>
 *     <td><a href="http://cldr.unicode.org/index/downloads/cldr-22-1">CLDR 22.1</a></td>
 *     <td><a href="http://www.unicode.org/versions/Unicode6.2.0/">Unicode 6.2</a></td></tr>
 * <tr><td>Android 4.4 (KitKat)</td>
 *     <td><a href="http://site.icu-project.org/download/51">ICU 51</a></td>
 *     <td><a href="http://cldr.unicode.org/index/downloads/cldr-23">CLDR 23</a></td>
 *     <td><a href="http://www.unicode.org/versions/Unicode6.2.0/">Unicode 6.2</a></td></tr>
 * <tr><td>Android 4.? (STOPSHIP)</td>
 *     <td><a href="http://site.icu-project.org/download/53">ICU 53</a></td>
 *     <td><a href="http://cldr.unicode.org/index/downloads/cldr-25">CLDR 25</a></td>
 *     <td><a href="http://www.unicode.org/versions/Unicode6.3.0/">Unicode 6.3</a></td></tr>
 * </table>
{quote}

Before trying anything, it would be helpful to have some code [~par.nils.amsen@gmail.com].
Code that can be imported into an IDE, as well as detailed instructions to reproduce the issue.
Then someone would need to dig a bit deeper than I did, and understand why the differences
for the abbreviated week day name.

I don't see what could be done in [lang], and believe we will be able to find something missing
in Android/libcore/icu for pt_PT, and then users will simply need to update their dependencies,
without any change here in [lang].

> FastDateFormat does not support 'EEE' and 'MMM' abbreviations for PT_pt
> -----------------------------------------------------------------------
>
>                 Key: LANG-1328
>                 URL: https://issues.apache.org/jira/browse/LANG-1328
>             Project: Commons Lang
>          Issue Type: Bug
>    Affects Versions: 3.3.2
>         Environment: Android
>            Reporter: Pär Nils Amsen
>         Attachments: android.png, oracle.png
>
>
> For the following statement:
> {code:java}
> FastDateFormat.getInstance("MMM", timeZone, new Locale("pt", "pt")).format(1494115200);
> {code}
> The outcome will be "dormingo" instead of "dor" in Portugese (pt_PT). I expect this to
be a bug since the only reason for FastDateFormat to not abbreviate the weekdays would be
that Portugese does not allow it, not very likely.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message