Improved handling of date/time patterns that have both a date and time portion

[sbrunot]

Here are two examples of date format for which the shim does not returns the same string than a native implementation:

{weekday: 'long'}

=> The native implementation returns "Monday" (if the date is a monday), while the shim returns "14 Mon" (if the date is a monday 14th)

{year: 'numeric', month: 'numeric', day: 'numeric', hour:'numeric', minute: 'numeric', second:'numeric', hour12: false}

=> The native implementation returns "10/21/2014, 14:18:34" while the shim returns "Tue, Oct 21, 2014 at 14:18:34"

[JCEmmons]

This is definitely a bug and might take some work. The problem is that the algorithm I'm using to go from the CLDR patterns to the requested patterns only does exact matching, and we need a more sophisticated algorithm to get all the reasonable possibilities. Neither example cited falls in the realm of what I would consider "acceptable behavior..."

[sbrunot]

Thanks for your answer John. Can you think of a workaround we could use while waiting for the new algorithm ?

[JCEmmons]

For the first one ( the long weekday problem ), a quick workaround would be to replace https://github.com/ibm-js/ecma402/blob/master/cldr/en/ca-gregorian.json#L222 with
"E": "EEEE",
instead of:
"E": "ccc",

Of course, this will only work for the English, if you are testing another locale, you would need to do similar if the data contained a "ccc" format. "ccc" means "stand-alone context", which I had neglected to consider when writing the original implementation.

The 2nd example is more involved - I have no quick workaround for that.

[JCEmmons]

The first example given by @sbrunot will be handled with issue #77

[JCEmmons]

The 2nd example given, ( i.e. one that has both a "date" and "time" portion ), is a bit trickier, partially because CLDR's dateTime formats ( the glue that goes between date and time ) was only designed to apply to the "stock" formats and not the "available" formats, which is what we are using. Right now, we are just forcing a single date/time format ( see https://github.com/ibm-js/ecma402/blob/master/Intl.js#L981 ) for the logic.

What I am going to need to do with this is to split down the request into the date portion vs. the time portion, and then use some set of rules to figure out which "glue" to use based on the date pattern. CLDR's spec ( tr35 ) doesn't really talk about how this should apply to availableFormats, but I think a pretty reasonable approach is as follows:

If the date pattern contains both a long weekday and long month name, use the "full" glue format. For example, "Friday, October 21, 2014 at 12:01 PM"

If the date pattern contains a long month name, use the "wide" glue format.
For example, "October 21, 2014 at 12:01 PM"

If the date pattern contains an abbreviated month name, use the "abbreviated" glue format.
For example, "Oct 21, 2014, 12:01 PM"

If the date pattern contains none of these ( i.e. the month is numeric ), then use the "short" glue format. For example, "10/21/2014, 12:01:36".

This should do a much better job of handling cases where both a date and time is present.