Tim Ellison wrote:
> Richard Liang wrote:
>
>> Hello Tim,
>>
>> I have raised Harmony-910[1] for this issue, patch is also available
>> :-) Would you please have a look at it. Thanks a lot.
>>
>
> I've had a look at it, but you don't appear to fix the problem described
> below...
>
>
Ah....., Let me explain it below. ;-)
>>> Richard Liang wrote:
>>>
>
> <snip>
>
>
>>> The reason is: In en_UK, a FULL style date formatter is the same as a
>>> LONG style date formatter. So the return value of format.toPattern()
>>> maybe "{0,date,long}", and according to the spec of
>>> MessageFormat.toPattern() "...The string is constructed from internal
>>> information and therefore *does not necessarily equal* the previously
>>> applied pattern." So I think it's a bug of the test case.
>>>
>
> So shouldn't you be removing the assertion that they are equal? It
> seems that the suggested patch is relying on a particular implementation
> in a given locale, but it still is asserting more than required by the
> specification.
>
>
Although the spec does not require the round-trip of applyPattern and
toPattern, we still want to get one *certain* pattern through toPattern.
Now the problem is the returned pattern is locale-dependent. I'm
uncertain about the reason to remove the assertion:
1) Because the behavior is not required by spec, or
2) Because the behavior is locale-dependent
Thanks a lot.
Best regards,
Richard
> Regards,
> Tim
>
>
--
Richard Liang
China Software Development Lab, IBM
|