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
