Locale-Sensitive JavaScript Method

date.toLocaleDateString();
date.toLocaleDateString(locales);
date.toLocaleDateString(locales, options);


Internationalization (I18n) Method Overview

The toLocaleDateString method returns the date part of the date object formatted using either the system's locale or the specified locale passed into the method. The options parameter can be used to override the default format.

For example:

var date = new Date();
var options = {year: "numeric", month: "long", day: "numeric"};
var result1 = date.toLocaleDateString("en-US", options);
var result2 = date.toLocaleDateString("it-IT", options);

var result3 = date.toLocaleDateString("en-US");

Results are:

result1: September 17, 2014
result2: 17 settembre 2014
result3: 9/17/2014


Click here (w3schools) and here (MDN) for additional details.

I18n Issues

Whether or not calling toLocaleDateString is an i18n issue is dependent on how it is being used in the application. Some possible issues are:

• There is no locales parameter passed into the method, which means the system's locale will be used to format the date.
• You want a fixed date format, regardless the locale. One reason might be that this date string is stored in a log file that is to remain in U.S. English.
• A large set of dates are being formatted to date strings and you want to improve the performance.

Suggested Replacement

Make sure that you pass in the application's locale so that the date will be formatted correctly; use the options parameter to customize the format.

If you want a fixed date format, regardless the locale, you could call toDateString, which will format the date/time using U.S. English. Call toISOString to format the date in a locale-independent way; the resulting ISO Standard date/time string is understandable in all locales.

To improve performance, you may want to call Intl.DateTimeFormat constructor, which returns a locale-sensitive format object that you can then repeatedly call its format method.

Globalyzer will detect this method and report it as an i18n issue. If you have determined that the call is being handled correctly, you can use Globalyzer's Ignore Comment functionality to ensure that it isn't picked up in a subsequent scan.