DateTimeFormat property values

Andrew Paprocki andrew at
Fri Mar 1 06:27:27 PST 2013

Looking at the Internationalization API, I noticed that DateTimeFormat
property values don't appear to align with the names that Unicode CLDR data
uses. The Unicode CLDR data specifies what format pieces actually look like
in every locale, so it would make sense to me to use their names and rely
on their data rather than re-inventing the wheel.

For example, in the context of "format" (as opposed to "standalone") month
representations in locale "es", this is specified:

1307                        <calendar type="gregorian">
1308                                <months>
1309                                        <monthContext type="format">
1310                                                <monthWidth
1311                                                        <month
1312                                                        <month
1324                                                <monthWidth type="wide">
1325                                                        <month
1326                                                        <month

Is "abbreviated" in CLDR equivalent to "narrow" or "short" in this spec? It
would make more sense to me to adopt the CLDR naming conventions so that
implementations can build the Internationalization support on top of the
Unicode data.

Related -- Properties such as "day" only contains values for "2-digit" and
"numeric", but CLDR data also provides "abbreviated", "short", and "wide"
in the format context:

1372                                                <dayWidth
1373                                                        <day
1381                                                <dayWidth type="short">
1382                                                        <day type="sun"
1390                                                <dayWidth type="wide">
1391                                                        <day

Curious to hear if there is a reason to stray from the CLDR specification
since it appears to be pretty complete for almost any need.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list