[proposal] expose internal date pattern resolved per instance

[tc39]

[proposal] expose internal date pattern resolved per instance

[caridy]

backpointer to an old task related to this proposal: https://bugs.ecmascript.org/show_bug.cgi?id=771

[zbraniecki]

Example of what this API would save us from doing: https://github.com/mozilla-b2g/gaia/blob/1360b05876d2def34a37c28e44d49e7e60dc2484/apps/system/js/value_selector/spin_date_picker.js#L120-L156

[caridy]

I need to talk to @bterlson about this to see how realistic this will be for Chakra/Edge since they don't use CLDR data.

[zbraniecki]

Is DateTimeFormat using raw CLDR? I'm a bit confused about how CLDR handles order of "hma" (where h is hour, m i minute and a is dayperiod) because there doesn't seem to be an entry with that name. So it seems that CLDR for locales that don't use dayperiod by default, doesn't provide a way to order with dayperiod. DateTimeFormat handles that, so it may be coming from somewhere else.

Also, Mozilla would be very interested in such data for our date/time pickers.

[caridy]

@zbraniecki for that particular case, they use hm instead of hma, which can be matched with the fact that for en the value of hour12 config is true by default. In other words, yes, it is the raw CLDR data:

"hm": "h:mm a"

while for en-GB we have:

"Hm": "HH:mm",

matching the default value for hour12, which if false.

[caridy]

I don't think I have answered your question, let me try again. the algo we have today does NOT use the key, it uses the value from CLDR to find the best match based on the provided configuration, which means we will either pickup entry hm or Hm depending of the value of hour12 (whether that's provided in the instance, or the default value per locale), in other words:

(new Intl.DateTimeFormat("en-US", { hour: "numeric", minute: "numeric" }));

will use h:mm a for en, and HH:mm for en-GB, if you add hour12 to that config, you can choose which one to use by forcing the value of it.

[zbraniecki]

I'm going to expose it internally for Gecko because we need this for date/time pickers.

I may be interested in championing it, but I'm a bit afraid of the scope of spec work to define all combinations that pattern can take depending on locale and options.

@caridy - am I correct to expect it to be a substantial amount of work or would you be ok to leave it as implementation specific?

[zbraniecki]

Alternatively, one can use formatToParts to build a placeholder:

var x = new Intl.DateTimeFormat('en-US', {
  hour: '2-digit',
  minute: '2-digit',
});
var parts = x.formatToParts(now);

parts.map(part => {
  switch (part.type) {
    case 'hour':
    case 'minute':
      return '--'
    default:
      return part.value;
  }
}).join('');

[zbraniecki]

I guess my question is - except of building placeholder patterns (which can be done using formatToParts), is there any other use case for the pattern?

[zbraniecki]

@eemeli, @rxaviers, @ericf, @littledan - any opinion on that?

If the only use case for the pattern is to create placeholders or pickers and we can already do that with formatToParts, I suggest we close this issue.

[eemeli]

I at least can't think of anything that could be done better with resolved.pattern rather than formatToParts.

[zbraniecki]

then I suggest we close this issue! :) @caridy, can you do this? I don't have the privs.

[caridy]

Yes, in fact chrome does not longer expose the internals of the DateTimeFormat, there is no reason to do so now that we have formatToParts.

[rxaviers]

👍 (although late 😊)