Decide behavior with gaps in Intl.DateTimeFormat options (replacement pattern)

[sffc]

Problem: A user builds an Intl.DateTimeFormat with non-contiguous options. For example:

new Intl.DateTimeFormat("en", {
  year: "numeric",
  day: "numeric"
});

What should the behavior be?

1. Garbage in, garbage out. (current behavior)
2. Throw an exception. (breaks the web)
3. Fill in the missing fields: between year and day, automatically assume month. (best attempt for what the user might want)

A problem with "garbage in, garbage out" is that you can get the CLDR replacement pattern exposed, as @anba pointed out in #346 (comment). Here is a list of current outputs in Chrome 78:

const fields = ["year", "month", "day", "hour", "minute", "second"];
for (let i=0; i<fields.length; i++) {
	for (let j=i+2; j<fields.length; j++) {
		const options = {};
		options[fields[i]] = "numeric";
		options[fields[j]] = "numeric";
		const fmt = new Intl.DateTimeFormat("en", options);
		console.log(fields[i] + "/" + fields[j] + ": " + fmt.format(new Date()));
	}
}

/*
year/day: 10 2019
year/hour: 2019, 3 PM
year/minute: 2019, 30
year/second: 2019, 33
month/hour: 12, 3 PM
month/minute: 12, 30
month/second: 12, 33
day/minute: 10, 30
day/second: 10, 33
hour/second: 3 PM (second: 33)
*/

I have a slight preference for adopting behavior 3 (fill in the missing fields). This behavior would be fully spec-compliant as-is, since the patterns are implementation-defined, but we could further codify this behavior into the spec to provide clarity to users.

CLDR issue about minute + dayPeriod:

https://unicode-org.atlassian.net/browse/CLDR-13184

[zbraniecki]

I have a slight preference for adopting behavior 3 (fill in the missing fields).

My concern about this approach is that it has a likelyhood of becoming a papercut giving developers an unexpected behavior.
I'm also not confident that we know what garbage is in every locale and culture. While year/day may make no sense in en-US, I'm not sure if I can make the same claim for every other one.

Finally, with the introduction of dateStyle/timeStyle which I expect to become the core way of specifying options, I expect the field specific options to end up being used only when the developer really needs a specific combination, and in such case, the argument that we're "helping users avoid mistakes" is weaken for me.

[srl295]

My concern about this approach is that it has a likelyhood of becoming a papercut giving developers an unexpected behavior.

@zbraniecki I'm going to comment on this on the CLDR issue.

[sffc]

We discussed this in CLDR-TC. Peter likes the approach (fill in missing fields) and suggested that we could do this in CLDR. Once CLDR supports it, then we could consider adding it as a spec requirement on the 402 level.

[sffc]

CLDR ticket: https://unicode-org.atlassian.net/browse/CLDR-13627

[sffc]

Let's wait on the CLDR ticket, and then decide what further action to take here in 402.

[gouaic]

😯😯