[threeten-dev] Possible addition of pattern letters in CLDR

[Dan Chiba]

Yoshito,

May I ask if we could file a LDMR enhancement for "f" and "p", is this 
something you could add to the ticket #5506?

Stephen,

For the shortest GMT format, there is only a slight possibility for JDK8 
to support it, in case the status of CLDR is ready and JSR-310 can 
afford the engineering cost in time. I just put an Github issue to track 
this fix as #173 <https://github.com/ThreeTen/threeten/issues/173>. 
Please put an RFE or other appropriate tag on it.

Regards,
-Dan

On 12/17/2012 3:02 AM, Stephen Colebourne wrote:
> On 14 December 2012 04:00, Dan Chiba<dan.chiba at oracle.com>  wrote:
>> Thank you for filing the CLDR ticket. Your proposal sounds great. May I ask
>> the status of the shortest GMT format? When could it be implemented by
>> vendors?
>>
>> As for punctuations, I think comma and dot are already locale sensitive for
>> number formatting, so it would be easy for people to understand how the
>> locale sensitive punctuations for date time formatting work. Because the
>> predefined formatting patterns for locales have the separators for date and
>> time fields and they are commonly used, it doesn't seem to be an issue that
>> there is no locale sensitive pattern letter for them. So I think I am only
>> interested in the decimal separator for fractional seconds. Alternatively,
>> if CLDR had predefined locale sensitive patterns with fractional seconds,
>> that could also be a solution. For instance, a predefined common pattern to
>> print hour, minute, second and millisecond for the US locale may look like
>> this:
>>
>> <dateFormatItem id="HmsS">HH:mm:ss.SSS</dateFormatItem>
> For everyones info, we previously had a letter "f", which meant output
> a fraction with a localized decimal point
>
>   HH:mm:ss.SSS - always use dot
>   HH:mm:ssfSSS - use localized decimal point (old JSR-310)
>   HH:mm:ssfff - possible localized decimal point alternative
>
> in JSR-310 we used "f" for exact length and "ff" for up to nanos length:
>   HH:mm:ssfSSS - print 3 digit fraction
>   HH:mm:ssfSS - print 2 digit fraction
>   HH:mm:ssffSSS - print at least 3 digits and a maximum of 9
>
> We don't have "f" right now, but there is the germ of a good idea in there.
>
>> Would you elaborate what "p" (prefix for padding) does? Does it make sense
>> to have it defined in LDML as well?
> Some examples:
>
>   MMM-dd ->  "Dec-07"
>   MMM-d ->  "Dec-7"
>   MMM-ppd ->  "Dec-*7"
>   MMM-pppd ->  "Dec-**7"
>
> (using * instead of space for clarity in this email)
>
> So, the "p" pattern letter means "pad the next field with spaces on
> the left to a width determined by the number of p characters". Thus
> "pp" means "pad the next field to a width of 2.
>
> I can't think how a pad width of 1 would be useful however, so it
> would be clearer to reduce the "p" level by one:
>
>   MMM-pd ->  "Dec-*7"
>   MMM-ppd ->  "Dec-**7"
>
> That would make "p" mean "pad the next field with spaces on the left
> to a width determined by the total of the number of p and value
> characters".
>
> So, "p" now means "pad the next field to a width of 2.
>
> It would be good to see "p" in LDML. We would need to agree on one of
> the two definitions above.
>
>> Also, do you think 310 can suppor the shortest GMT format if its status is
>> ready for implementation?
> If the data is available in Java, we can find a way to support it,
> time permitting.
>
> Stephen