Opened 13 years ago
Closed 12 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: | [email protected]…, [email protected]… | |
Blocked By: | Blocking: |
Description
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.
Change History (6)
comment:1 Changed 13 years ago by
Cc: | [email protected]… added |
---|
comment:2 Changed 13 years ago by
Milestone: | → 1.2 |
---|
comment:3 Changed 13 years ago by
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 13 years ago by
Milestone: | 1.2 → 1.3 |
---|---|
Priority: | normal → low |
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 12 years ago by
Milestone: | 1.3 → future |
---|
comment:6 Changed 12 years ago by
Milestone: | future → 1.2 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
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.
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:
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.