Missing date format option - days-format-narrow

[guest]

The unicode date formatting spec mentions that "EEEEE" should map to the single-character representation of the day - e.g. S or T.

The dojo.date.locale class correctly maps "EEEEE" to the format "days-format-narrow", and goes to look that up from the gregorian.js resource bundle. Unfortunately, it's not there.

The following code:

dojo.date.locale.format(new Date(), { selector: "date", datePattern: "EEEEE"});

results in this error: TypeError?: bundle[propD] has no properties message=bundle[propD] has no properties

The fix is simple enough - add a "days-format-narrow" option into the relevant gregorian.js bundles. Here's a suitable value for the en bundle:

"days-format-narrow":["S","M","T","W","T","F","S"]

Note that there are "days-standAlone-narrow" entries in most (if not all) of the EN bundles.

[Adam Peller]

These entries are generated from the CLDR, so we shouldn't have to create our own entries/translations.

According to the spec, we should be using the 'format' variety of narrow day names in this context, as we're formatting a date string. Also, according to the spec, a lookup for stand-alone should also check for format, but not the other way around:

If the stand-alone form does not exist (in the chain up to root), then it inherits from the format form. See Multiple Inheritance.

So it sounds like the entries for dateContext="stand-alone" should be moved to dateContext="format" where there isn't one, and therefore a gap in the CLDR.

[Adam Peller]

hmm... I see, those 'stand-alone' values are not valid 'format' values, so it sounds like there are no valid format options for days-narrow?!

The values in formats must be distinct; that is, "S" could not be used both for Saturday and for Sunday. The same is not true for stand-alone values; they might only be distinguished by context, especially in the narrow format.

So what then is supposed to happen when EEEEE is used in a format? Is it acceptable to have incomplete data?

[Adam Peller]

John pointed out that there are aliases in the LDML, which we don't support, so actually, the code is supposed to look at days-standAlone-narrow when days-format-narrow doesn't exist! He said this might be improved in CLDR 1.7, or even de-supported. This feels like an edge case -- is EEEEE needed in a real date format, or is this just for completeness?

[Adam Peller]

After applying the various fixes for #7188 to transform the aliases in the LDML markup, we no longer seem to get an exception when looking up days-format-narrow. However, the data is identical to the standalone, which seems to defy the definition that each day have a unique string -- that's a CLDR problem, I guess.