JavaScript Intl.DateTimeFormat.format vs Date.toLocaleString

I would like to print a string representing a Date, using a specific timezone, locale, and display options.

Which one of these should I use?

  1. Intl.DateTimeFormat.prototype.format
  2. Date.prototype.toLocaleString()

It seems like they return identical results.

const event = new Date(1521065710000);

const options = {
  day: 'numeric',
  month: 'long',
  weekday: 'short',
  hour: 'numeric',
  minute: 'numeric',
  timeZoneName: 'short',
  timeZone: 'America/Los_Angeles',
};

console.log(event.toLocaleString('en-US', options));
// "Wed, March 14, 3:15 PM PDT"

console.log(new Intl.DateTimeFormat('en-US', options).format(event));
// "Wed, March 14, 3:15 PM PDT"

This is very close to being off–topic as opinion based, but here goes anyway.

Which one of these should I use?

Date.prototype.toLocaleString was originally solely implementation dependent and varied quite a bit across browsers. When support for the Intl object was added (ECMAScript 2015, ed 6) then toLocaleString was allowed to support the same options. While support isn't mandated by ECMA-262, probably all current implementations support it.

Note that this did not remove the allowed implementation variability, it just provided some formatting options based on language, region and dialect (and also timezone options based on the IANA time zone database identifiers and values).

The Intl object (and hence toLocaleString) is based on ECMA-402, which doesn't strictly specify formatting, so there is still some room for implementations to differ. The biggest differences are in regard to timezone names (for which there is no standard) and placement of commas, spaces, etc.

However, for most practical purposes, whether you use the Intl object or toLocaleString is up to you, I don't think there's any technical reason to prefer one over the other. While the results for both should be identical for a particular implementation, don't expect the resulting string to be exactly identical across implementations or to conform to a particular format for a given BCP 47 language tag.

Intl DateTimeFormat.format and Date.toLocaleString output different , toLocaleString output different results · javascript date internationalization. I'm not sure where this is defined, but if I have a Date object and want  The definition of 'Intl.DateTimeFormat.format' in that specification. Browser compatibility The compatibility table on this page is generated from structured data.

Addition to points that others issued, I saw a difference with default formats (options):

const event = new Date(1521065710000);

//const options = ...

console.log(event.toLocaleString('en-US' /*, options*/));
// "3/15/2018, 1:45:10 AM"

console.log(new Intl.DateTimeFormat('en-US' /*, options*/).format(event));
// "3/15/2018"

Intl.DateTimeFormat, The Intl.DateTimeFormat.prototype.format() method formats a date according to the locale and formatting options of this Intl.DateTimeFormat  Intl.DateTimeFormat.prototype.format() Getter function that formats a date according to the locale and formatting options of this DateTimeFormat object. Intl.DateTimeFormat.prototype.formatToParts() Returns an Array of objects representing the date string in parts that can be used for custom locale-aware formatting.

The Internationalisation API isn't supported in all browsers just yet - notably, IE10 and below and UC Browser for Android 11.8. If you want to support those browsers, use ToLocaleString. (Though if the Internationalisation API isn't supported, what ToLocalString returns is implementation-dependent.)

Intl.DateTimeFormat.prototype.format is designed for the use of formatting large groups of Dates - rather than setting the locale and options every time, you set them once and use the resulting format function from then on.

Intl.DateTimeFormat.prototype.format(), An example of such task is how to incorporate the date/time formatting OS user toLocaleString(navigator.locales, Intl.DateTimeFormat. I asked the committee about style: "date-short" vs dateStyle: "short" . will be more platforms that will want to use JS based Intl API and will want this feature (Electron?) dateObj .toLocaleString ( [ locales [, options ]]) Check the Browser compatibility section to see which browsers support the locales and options arguments, and the Example: Checking for support for locales and options arguments for feature detection. locales Optional. A string with a BCP 47 language tag, or an array of such strings. To use the

short/medium/long/full style for Intl.DateTimeFormat · Issue #108 , Intl is a powerful object that exposes the JavaScript Intl.Collator : gives you access to language-sensitive string comparison; Intl.DateTimeFormat : gives you access to language-sensitive date and time formatting; Intl.NumberFormat It can accept a string, or an array: toLocaleString(); Date.prototype. The toLocaleString () method converts a Date object to a string, using locale settings. The default language depends on the locale setup on your computer. Browser Support. #N#toLocaleString () Date .toLocaleString ( locales, options) Parameter Values. Optional. Which language specific format to use. Click on the "Try it" button to see all

JavaScript Internationalization, Date formatting in JavaScript can get trick to say the least. Let's see how Intl.​DateTimeFormat can help. Or in the head:. The toLocaleDateString () method returns a string with a language-sensitive representation of the date portion of the date. The locales and options arguments let applications specify the language whose formatting conventions should be used and allow to customize the behavior of the function. The values you can passed in options for different keys:

Formatting dates in JavaScript with Intl.DateTimeFormat, The Intl.DateTimeFormat object is a constructor for objects that enable language sensitive date and time formatting. A string with a BCP 47 language tag, or an array of such strings. UTC(2012, 11, 20, 3, 0, 0)); // toLocaleString without arguments depends on the implementation, // the default locale, and the default time  This is not a solution to obtaining the format string, but you can use ((new Intl.DateTimeFormat()).format(new Date()); to get a formatted date string. – Karl Wilbur Jul 27 '18 at 14:16 For now, (new Intl.DateTimeFormat()).resolvedOptions() - will give you format object – iegik Jul 29 '18 at 14:06

Comments
  • For all practical purposes, they are identical. toLocaleString was originally purely implementation dependent, but now it also supports the same options as the Intl object, both are based on the ECMA-402 Internationalization API. Note that ECMA-402 does not specify the format, it only requires conformity with regional or cultural preferences, which might differ between implementations, even for the same language and region. So you may not get exactly consistent results (but pretty close).
  • @RobG Yes of course, awakening typo... and what I thought to remember about perfs was probably just the note in MDN.
  • @Kaiido—no problem. ;-)
  • Thanks, this is the information I was interested in. I'm happy to edit my question to not be off-topic. Maybe Are there any advantages / disadvantages to using these two approaches? or Why do there exist two ways to accomplish the following? or What is the history of these two methods? or some other suggestion
  • Yes, the Date AI's have a simple, straightforward way of specifying which components should be included, ie. toLocaleDateString() vs toLocaleTimeString() vs toLocalString(). With the Intl API's it seems to be inferred from the options.