Opened 11 years ago

Closed 11 years ago

#6800 closed defect (fixed)

Missing date format option - days-format-narrow

Reported by: guest Owned by: Adam Peller
Priority: low Milestone: 1.2
Component: Date Version: 1.1.0
Keywords: Cc: robert.watkins@…, emmo@…
Blocked By: Blocking:


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

The 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: 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:


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

Change History (6)

comment:1 Changed 11 years ago by Adam Peller

Cc: emmo@… added

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.

comment:2 Changed 11 years ago by Adam Peller

Milestone: 1.2

comment:3 Changed 11 years ago by 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?

comment:4 Changed 11 years ago by Adam Peller

Milestone: 1.21.3
Priority: normallow

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?

comment:5 Changed 11 years ago by Adam Peller

Milestone: 1.3future

comment:6 Changed 11 years ago by Adam Peller

Milestone: future1.2
Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.