Support formatting milliseconds with Intl.DateTimeFormat API

[HolgerJeromin]

I need to format a Timestamp in a specific locale (not utc, not browser locale). But I must have the millisecond part of the date, too. My first attempt was second:'numeric' with the DateTimeFormat API:

new Intl.DateTimeFormat(
    'de-DE', // german as an example, user selectable
    { 
        year: 'numeric', month: 'numeric',  day: 'numeric', 
        hour: 'numeric', minute: 'numeric', 
        second: 'numeric',
        hour12: false
    }
)
.format(new Date()); // Date as an example

But the result is something like 26.11.2018, 09:31:04 and not 26.11.2018, 09:31:04,243.

Asked first at stackoverflow.

[ray007]

Or maybe something more generic for the sub-second part, like the "S" format in ICU.
See http://userguide.icu-project.org/formatparse/datetime and https://www.unicode.org/reports/tr35/tr35-dates.html#dfst-second

[chriscalo]

Is this getting resolved via #347? That seems to match the API in MDN's docs of Intl.DateTimeFormat: (paraphrased)

// sometimes you want to be very precise
var options = {
  hour: 'numeric', minute: 'numeric', second: 'numeric', 
  timeZone: 'Australia/Sydney',
  timeZoneName: 'short',
  fractionalSecondDigits: 3,
};
console.log(new Intl.DateTimeFormat('en-AU', options).format(date));
// → "2:00:00.200 pm AEDT"

An alternative that more closely matches the other option values ('short', 'long', etc) and also matches the output for fractionalSecond ('.0', '.00', '.000') in MDN's Intl.DateTimeFormat.prototype.formatToParts() docs.

// sometimes you want to be very precise
var options = {
  hour: 'numeric', minute: 'numeric', second: 'numeric', 
  timeZone: 'Australia/Sydney',
  timeZoneName: 'short',
  
  // 'narrow' => '.0'
  // 'short' => '.00'
  // 'long' => '.000'
  fractionalSecond: 'long',
};
console.log(new Intl.DateTimeFormat('en-AU', options).format(date));
// → "2:00:00.200 pm AEDT"

[ray007]

Seems that way.
Did someone start a competition for longest possible option name for new things?

[sffc]

Yes, this is #347. Sorry for the long name; we arrived at fractionalSecondDigits because we want it to eventually scale up to 9 digits for nanoseconds when the Temporal proposal comes along

[HolgerJeromin]

Thank you for all your work. Especially @FrankYFTang !