Since the spec states that CLDR data is the recommended source for implementation, I would proposed that the allowed values in Table 3, Section 12.1.1.1 be modified to be identical with the names in CLDR, so that there is no confusion, and that if CLDR were to add additional lengths over time, we could do so with no confusion for implementers. Also, examples from English would be helpful here. I would propose changing as follows:
( conforming to the upcoming CLDR 22 release )
Weekday - ( wide (Sunday) - abbreviated (Sun) - Short (Su) - Narrow (S) )
Era - wide - abbreviated - narrow
Month - "2-digit", "numeric", "wide", "abbreviated", "narrow"
The recommendation to use CLDR is in a non-normative note, and we know that there will be at least one implementation that won't be based on CLDR, so we can't assume that all implementations will support all CLDR features, or will use the same strings.
The proposal to change the values in table 3 should be brought up on es-discuss@.
Understood - and so I'm not asking you to support everything that CLDR does. It just seems that in this case it would be much better to make it painfully obvious to those using CLDR as the basis for implementation exactly which forms they should be pulling from the CLDR.
So in this case, it's pretty simple, as follows:
Right now in the spec, for weekday, era, and month, you have:
"narrow", "short", and "long".
By simply changing the words to:
"narrow", "abbreviated", and "wide" respectively, we've made it clear the correlation between ECMAScript and CLDR, and there is a lot smaller chance for confusion, especially in the case of weekdays, which now have 4 widths in CLDR instead of 3 ( narrow, short, abbreviated, and wide ).
As it stands now, an implementer using CLDR as the basis for the implementation wouldn't know whether he should use (narrow,short,wide) or (narrow,abbreviated,wide) to match up with ECMAScript's (narrow,short,long) for weekdays.
A simple wording change could avoid a lot of confusion.
We discussed this at the July 2012 TC 39 meeting, and concluded that the names used in the API should not be changed to accommodate implementation concerns. Instead, I extended the non-normative note recommending CLDR to also recommend using CLDR “abbreviated” strings for DateTimeFormat “short” strings, and CLDR “wide” strings for DateTimeFormat “long” strings.