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

-- 
Richard Liang
China Software Development Lab, IBM 


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