On 4 June 2011 18:35, Henri Yandell wrote:
> Seems good. Something other than NULL probably; and probably should
> come up with some bizarre negative number to stay out of the way of
> any future JDK items.
Yes, that is a possible issue here. The current JDK only uses positive
integers, so -1 may
Seems good. Something other than NULL probably; and probably should
come up with some bizarre negative number to stay out of the way of
any future JDK items.
On Fri, Jun 3, 2011 at 8:06 PM, sebb wrote:
> On 4 June 2011 03:44, Henri Yandell wrote:
>> Looking more at this one, it looks like the In
On 4 June 2011 03:44, Henri Yandell wrote:
> Looking more at this one, it looks like the Integer is required as
> null is a valid use case. So moving simply to int is out, but
> rethinking it seems very doable.
I did some work on this, and I think we can add another style value
which means don't
Looking more at this one, it looks like the Integer is required as
null is a valid use case. So moving simply to int is out, but
rethinking it seems very doable.
Note that this isn't a public API; FormatCache is for now a
refactoring out of FastDateFormat to allow a later FastDateParser.
I've add
On Wed, May 18, 2011 at 8:17 AM, Gary Gregory wrote:
> On Wed, May 18, 2011 at 9:37 AM, sebb wrote:
>
>> I think the method (new to 3.0)
>>
>> FormatCache.getDateTimeInstance(Integer dateStyle, Integer timeStyle,
>> TimeZone timeZone, Locale locale)
>>
>> should be changed to use ints, as all the
On Wed, May 18, 2011 at 9:37 AM, sebb wrote:
> I think the method (new to 3.0)
>
> FormatCache.getDateTimeInstance(Integer dateStyle, Integer timeStyle,
> TimeZone timeZone, Locale locale)
>
> should be changed to use ints, as all the existing callers use ints.
>
> Furthermore, the parameters hav
