harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Liang <richard.lian...@gmail.com>
Subject Re: [build] status
Date Wed, 19 Jul 2006 02:44:04 GMT

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,
> Regards,
> Tim

Richard Liang
China Software Development Lab, IBM 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message