This is the HTML rendering of ECMA-402 Edition 1.0, ECMAScript Internationalization API Specification.
The PDF rendering of this document is located at http://www.ecma-international.org/ecma-402/1.0/ECMA-402.pdf.
The PDF version is the definitive specification. Any discrepancies between this HTML version and the PDF version are unintentional.
The ECMAScript Internationalization API provides key language-sensitive functionality as a complement to the ECMAScript Language Specification, 5.1 edition or successor. Its functionality has been selected from that of well-established internationalization APIs such as those of the Internationalization Components for Unicode (ICU) library, of the .NET framework, or of the Java platform.
The API was developed by an ad-hoc group established by Ecma TC 39 in September 2010 based on a proposal by Nebojša Ćirić and Jungshik Shin.
Internationalization of software is never complete. We expect significant enhancements in future editions of this specification.
Editor
Norbert Lindenberg
Contributors
Eric Albright
Nebojša Ćirić
Peter Constable
Mark Davis
Richard Gillam
Steven Loomis
Mihai Nita
Addison Phillips
Roozbeh Pournader
Jungshik Shin
Shawn Steele
Allen Wirfs-Brock
Feedback provided by Erik Arvidsson, John J. Barton, Zbigniew Braniecki, Marcos Cáceres, Brendan Eich, John Emmons, Gordon P. Hemsley, David Herman, Luke Hoban, Oliver Hunt, Suresh Jayabalan, Yehuda Katz, Mark S. Miller, Andrew Paprocki, Adam Peller, Axel Rauschmayer, Andreas Rossberg, Alex Russell, Markus Scherer, Dmitry Soshnikov, Yusuke Suzuki, John Tamplin, Rick Waldron, Anton Yatsenko, Nicholas Zakas.
This Ecma Standard has been adopted by the General Assembly of December 2012.
COPYRIGHT NOTICE
© 2012 Ecma International
This document may be copied, published and distributed to others, and certain derivative works of it may be prepared, copied, published, and distributed, in whole or in part, provided that the above copyright notice and this Copyright License and Disclaimer are included on all such copies and derivative works. The only derivative works that are permissible under this Copyright License and Disclaimer are:
(i) works which incorporate all or portion of this document for the purpose of providing commentary or explanation (such as an annotated version of the document),
(ii) works which incorporate all or portion of this document for the purpose of incorporating features that provide accessibility,
(iii) translations of this document into languages other than English and into different formats and
(iv) works by making use of this specification in standard conformant products by implementing (e.g. by copy and paste wholly or partly) the functionality therein.
However, the content of this document itself may not be modified in any way, including by removing the copyright notice or references to Ecma International, except as required to translate it into languages other than English or into a different format.
The official version of an Ecma International document is the English language version on the Ecma International website. In the event of discrepancies between a translated version and the official version, the official version shall govern.
The limited permissions granted above are perpetual and will not be revoked by Ecma International or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and ECMA INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Standard defines the application programming interface for ECMAScript objects that support programs that need to adapt to the linguistic and cultural conventions used by different human languages and countries.
A conforming implementation of the ECMAScript Internationalization API must conform to the ECMAScript Language Specification, 5.1 edition or successor, and must provide and support all the objects, properties, functions, and program semantics described in this specification.
A conforming implementation of the ECMAScript Internationalization API is permitted to provide additional objects, properties, and functions beyond those described in this specification. In particular, a conforming implementation of the ECMAScript Internationalization API is permitted to provide properties not described in this specification, and values for those properties, for objects that are described in this specification. A conforming implementation is not permitted to add optional arguments to the functions defined in this specification.
A conforming implementation is permitted to accept additional values, and then have implementation-defined behaviour instead of throwing a RangeError, for the following properties of options arguments:
The options property localeMatcher in all constructors and supportedLocalesOf methods.
The options properties usage and sensitivity in the Collator constructor.
The options properties style and currencyDisplay in the NumberFormat constructor.
The options properties minimumIntegerDigits, minimumFractionDigits, maximumFractionDigits, minimumSignificantDigits, and maximumSignificantDigits in the NumberFormat constructor, provided that the additional values are interpreted as integer values higher than the specified limits.
The options property timeZone in the DateTimeFormat constructor, provided that the additional acceptable input values are case-insensitive matches of Zone or Link identifiers in the IANA time zone database and are canonicalized to Zone identifiers in the casing used in the database for the timeZone property of the object returned by DateTimeFormat.resolvedOptions, except that "Etc/GMT" shall be canonicalized to "UTC".
The options properties listed in table 3 in the DateTimeFormat constructor.
The options property formatMatcher in the DateTimeFormat constructor.
The following referenced documents are required for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
ECMA-262, ECMAScript Language Specification, 5.1 edition or successor
https://www.ecma-international.org/publications-and-standards/standards/ecma-262/
NOTE Throughout this document, the phrase “ES5, x”, where x is a sequence of numbers separated by periods, may be used as shorthand for “ECMAScript Language Specification, 5.1 edition, subclause x”.
ISO/IEC 10646:2003: Information Technology – Universal Multiple-Octet Coded Character Set (UCS) plus Amendment 1:2005 and
Amendment 2:2006, plus additional amendments and corrigenda, or successor
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=39921
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=40755
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=41419
ISO 4217:2008, Codes for the representation of currencies and funds, or successor
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=46121
IETF BCP 47:
RFC 5646, Tags for Identifying Languages, or successor
http://tools.ietf.org/html/rfc5646
RFC 4647, Matching of Language Tags, or successor
http://tools.ietf.org/html/rfc4647
IETF RFC 6067, BCP 47 Extension U, or successor
http://tools.ietf.org/html/rfc6067
IANA Time Zone Database
http://www.iana.org/time-zones/
The Unicode Standard, Version 5.0, or successor
http://www.unicode.org/versions/latest
Unicode Technical Standard 35, Unicode Locale Data Markup Language, version 21.0.1 or successor
http://unicode.org/reports/tr35/
This section contains a non-normative overview of the ECMAScript Internationalization API.
Internationalization of software means designing it such that it supports or can be easily adapted to support the needs of users speaking different languages and having different cultural expectations, and enables worldwide communication between them. Localization then is the actual adaptation to a specific language and culture. Globalization of software is commonly understood to be the combination of internationalization and localization. Globalization starts at the lowest level by using a text representation that supports all languages in the world, and using standard identifiers to identify languages, countries, time zones, and other relevant parameters. It continues with using a user interface language and data presentation that the user understands, and finally often requires product-specific adaptations to the user’s language, culture, and environment.
The ECMAScript Language Specification lays the foundation by using Unicode for text representation and by providing a few language-sensitive functions, but gives applications little control over the behaviour of these functions. The ECMAScript Internationalization API builds on this by providing a set of customizable language-sensitive functionality. The API is useful even for applications that themselves are not internationalized, as even applications targeting only one language and one region need to properly support that one language and region. However, the API also enables applications that support multiple languages and regions, even concurrently, as may be needed in server environments.
The ECMAScript Internationalization API is designed to complement the ECMAScript Language Specification by providing key language-sensitive functionality. The API can be added to an implementation of the ECMAScript Language Specification, 5.1 edition or successor.
The ECMAScript Internationalization API provides three key pieces of language-sensitive functionality that are required in most applications: String comparison (collation), number formatting, and date and time formatting. While the ECMAScript Language Specification provides functions for this basic functionality (String.prototype.localeCompare, Number.prototype.toLocaleString, Date.prototype.toLocaleString, Date.prototype.toLocaleDateString, and Date.prototype.toLocaleTimeString), it leaves the actual behaviour of these functions largely up to implementations to define. The Internationalization API Specification provides additional functionality, control over the language and over details of the behaviour to be used, and a more complete specification of required functionality.
Applications can use the API in two ways:
The Intl object is used to package all functionality defined in the ECMAScript Internationalization API to avoid name collisions.
Due to the nature of internationalization, the API specification has to leave several details implementation dependent:
The set of locales that an implementation supports with adequate localizations: Linguists estimate the number of human languages to around 6000, and the more widely spoken ones have variations based on regions or other parameters. Even large locale data collections, such as the Common Locale Data Repository, cover only a subset of this large set. Implementations targeting resource-constrained devices may have to further reduce the subset.
The exact form of localizations such as format patterns: In many cases locale-dependent conventions are not standardized, so different forms may exist side by side, or they vary over time. Different internationalization libraries may have implemented different forms, without any of them being actually wrong. In order to allow this API to be implemented on top of existing libraries, such variations have to be permitted.
Subsets of Unicode: Some operations, such as collation, operate on strings that can include characters from the entire Unicode character set. However, both the Unicode standard and the ECMAScript standard allow implementations to limit their functionality to subsets of the Unicode character set. In addition, locale conventions typically don’t specify the desired behaviour for the entire Unicode character set, but only for those characters that are relevant for the locale. While the Unicode Collation Algorithm combines a default collation order for the entire Unicode character set with the ability to tailor for local conventions, subsets and tailorings still result in differences in behaviour.
This standard uses a subset of the notational conventions of the ECMAScript Language Specification, 5.1 edition:
NOTE As described in the ECMAScript Language Specification, algorithms are used to precisely specify the required semantics of ECMAScript constructs, but are not intended to imply the use of any specific implementation technique. Internal properties are used to define the semantics of object values, but are not part of the API. They are defined purely for expository purposes. An implementation of the API must behave as if it produced and operated upon internal properties in the manner described here.
In addition, the Record specification type is used to describe data aggregations within the algorithms of this specification.
A Record type value consists of one or more named fields. The value of each field is an ECMAScript type value. Field names are
always enclosed in double brackets, for example [[field1]]. Field names can also be provided by a variable: The notation
“[[<name>]]” denotes a field whose name is given by the variable name, which must have a String
value. For example, if a variable s has the value "a"
, then [[<s>]] denotes the field
[[a]].
In specification text and algorithms, dot notation may be used to refer to a specific field of a Record value. For example, if r is a record, then r.[[field1]] is shorthand for “the field of r named [[field1]]”.
For ECMAScript objects, this standard may use variable-named internal properties: The notation “[[<name>]]”
denotes an internal property whose name is given by the variable name, which must have a String value. For example,
if a variable s has the value "a"
, then [[<s>]] denotes the [[a]] internal
property.
This clause describes the String values used in the ECMAScript Internationalization API to identify locales, currencies, and time zones.
The String values used to identify locales, currencies, and time zones are interpreted in a case-insensitive manner, treating the Unicode Basic Latin characters "A" to "Z" (U+0041 to U+005A) as equivalent to the corresponding Basic Latin characters "a" to "z" (U+0061 to U+007A). No other case folding equivalences are applied. When mapping to upper case, a mapping shall be used that maps characters in the range "a" to "z" (U+0061 to U+007A) to the corresponding characters in the range "A" to "Z" (U+0041 to U+005A) and maps no other characters to the latter range.
EXAMPLES "ß" (U+00DF) must not match or be mapped to "SS" (U+0053, U+0053). "ı" (U+0131) must not match or be mapped to "I" (U+0049).
The ECMAScript Internationalization API identifies locales using language tags as defined by IETF BCP 47 (RFCs 5646 and 4647 or their successors), which may include extensions such as those registered through RFC 6067. Their canonical form is specified in RFC 5646 section 4.5 or its successor.
BCP 47 language tags that meet those validity criteria of RFC 5646 section 2.2.9 that can be verified without reference to the IANA Language Subtag Registry are considered structurally valid. All structurally valid language tags are valid for use with the APIs defined by this standard. However, the set of locales and thus language tags that an implementation supports with adequate localizations is implementation dependent. The constructors Collator, NumberFormat, and DateTimeFormat map the language tags used in requests to locales supported by their respective implementations.
This standard uses the term “Unicode locale extension sequence” for any substring of a language tag that starts with a separator "-" and the singleton "u" and includes the maximum sequence of following non-singleton subtags and their preceding "-" separators.
The IsStructurallyValidLanguageTag abstract operation verifies that the locale argument (which must be a String value)
The abstract operation returns true if locale can be generated from the ABNF grammar in section 2.1 of the RFC, starting with Language-Tag, and does not contain duplicate variant or singleton subtags (other than as a private use subtag). It returns false otherwise. Terminal value characters in the grammar are interpreted as the Unicode equivalents of the ASCII octet values given.
The CanonicalizeLanguageTag abstract operation returns the canonical and case-regularized form of the locale argument (which must be a String value that is a structurally valid BCP 47 language tag as verified by the IsStructurallyValidLanguageTag abstract operation). It takes the steps specified in RFC 5646 section 4.5, or successor, to bring the language tag into canonical form, and to regularize the case of the subtags, but does not take the steps to bring a language tag into “extlang form” and to reorder variant subtags.
The specifications for extensions to BCP 47 language tags, such as RFC 6067, may include canonicalization rules for the extension subtag sequences they define that go beyond the canonicalization rules of RFC 5646 section 4.5. Implementations are allowed, but not required, to apply these additional rules.
The DefaultLocale abstract operation returns a String value representing the structurally valid (6.2.2) and canonicalized (6.2.3) BCP 47 language tag for the host environment’s current locale.
The ECMAScript Internationalization API identifies currencies using 3-letter currency codes as defined by ISO 4217. Their canonical form is upper case.
All well-formed 3-letter ISO 4217 currency codes are allowed. However, the set of combinations of currency code and language tag for which localized currency symbols are available is implementation dependent. Where a localized currency symbol is not available, the ISO 4217 currency code is used for formatting.
The IsWellFormedCurrencyCode abstract operation verifies that the currency argument (after conversion to a String value) represents a well-formed 3-letter ISO currency code. The following steps are taken:
The ECMAScript Internationalization API defines a single time zone name, "UTC"
, which identifies the UTC time
zone.
The Intl.DateTimeFormat constructor allows this time zone name; if the time zone is not specified, the host environment’s current time zone is used. Implementations shall support UTC and the host environment’s current time zone (if different from UTC) in formatting.
NOTE The Conformance clause allows implementations to accept additional time zone names under specified conditions.
Unless specified otherwise in this document, the objects, functions, and constructors described in this standard are subject to the generic requirements and restrictions specified for standard built-in ECMAScript objects in the ECMAScript Language Specification 5.1 edition, introduction of clause 15, or successor.
The Intl object is a standard built-in object that is the initial value of the Intl
property of the global
object.
The value of the [[Prototype]] internal property of the Intl object is the built-in Object prototype object specified by the ECMAScript Language Specification.
The Intl object does not have a [[Construct]] internal property; it is not possible to use the Intl object as a constructor with the new operator.
The Intl object does not have a [[Call]] internal property; it is not possible to invoke the Intl object as a function.
The value of each of the standard built-in properties of the Intl object is a constructor. The behaviour of these constructors is specified in the following clauses: Collator (10), NumberFormat (11), and DateTimeFormat (12).
The constructors for the objects providing locale sensitive services, Collator, NumberFormat, and DateTimeFormat, use a common pattern to negotiate the requests represented by the locales and options arguments against the actual capabilities of their implementations. The common behaviour is described here in terms of internal properties describing the capabilities and of abstract operations using these internal properties.
The constructors Intl.Collator, Intl.NumberFormat, and Intl.DateTimeFormat have the following internal properties:
[[availableLocales]] is a List that contains structurally valid (6.2.2) and canonicalized (6.2.3) BCP 47 language tags identifying the locales for which the implementation provides the functionality of the constructed objects. Language tags on the list must not have a Unicode locale extension sequence. The list must include the value returned by the DefaultLocale abstract operation (6.2.4), and must not include duplicates. Implementations must include in [[availableLocales]] locales that can serve as fallbacks in the algorithm used to resolve locales (see 9.2.5). For example, implementations that provide a "de-DE" locale must include a "de" locale that can serve as a fallback for requests such as "de-AT" and "de-CH". For locales that in current usage would include a script subtag (such as Chinese locales), old-style language tags without script subtags must be included such that, for example, requests for "zh-TW" and "zh-HK" lead to output in traditional Chinese rather than the default simplified Chinese. The ordering of the locales within [[availableLocales]] is irrelevant.
[[relevantExtensionKeys]] is an array of keys of the language tag extensions defined in Unicode Technical Standard 35 that are relevant for the functionality of the constructed objects.
[[sortLocaleData]] and [[searchLocaleData]] (for Intl.Collator) and [[localeData]] (for Intl.NumberFormat and Intl.DateTimeFormat) are objects that have properties for each locale contained in [[availableLocales]]. The value of each of these properties must be an object that has properties for each key contained in [[relevantExtensionKeys]]. The value of each of these properties must be a non-empty array of those values defined in Unicode Technical Standard 35 for the given key that are supported by the implementation for the given locale, with the first element providing the default value.
EXAMPLE An implementation of DateTimeFormat might include the language tag "th" in its [[availableLocales]] internal property, and must (according to 12.2.3) include the key "ca" in its [[relevantExtensionKeys]] internal property. For Thai, the "buddhist" calendar is usually the default, but an implementation might also support the calendars "gregory", "chinese", and "islamicc" for the locale "th". The [[localeData]] internal property would therefore at least include {"th": {ca: ["buddhist", "gregory", "chinese", "islamicc"]}}.
Where the following abstract operations take an availableLocales argument, it must be an [[availableLocales]] List as specified in 9.1.
The abstract operation CanonicalizeLocaleList takes the following steps:
new Array(locales)
where
Array
is the standard built-in constructor with that name and locales is the value of
locales."length"
.NOTE Non-normative summary: The abstract operation interprets the locales argument as an array and copies its elements into a List, validating the elements as structurally valid language tags and canonicalizing them, and omitting duplicates.
NOTE Requiring kValue to be a String or Object means that the Number value
NaN will not be interpreted as the language tag "nan"
, which stands for Min Nan Chinese.
The BestAvailableLocale abstract operation compares the provided argument locale, which must be a String value with a structurally valid and canonicalized BCP 47 language tag, against the locales in availableLocales and returns either the longest non-empty prefix of locale that is an element of availableLocales, or undefined if there is no such element. It uses the fallback mechanism of RFC 4647, section 3.4. The following steps are taken:
"-"
(U+002D) within candidate.
If that character does not occur, return undefined."-"
occurs at index pos-2 of candidate, then
decrease pos by 2.The LookupMatcher abstract operation compares requestedLocales, which must be a List as returned by CanonicalizeLocaleList, against the locales in availableLocales and determines the best available language to meet the request. The following steps are taken:
"-"
of the first Unicode
locale extension sequence within locale.NOTE The algorithm is based on the Lookup algorithm described in RFC 4647 section 3.4, but options specified through Unicode locale extension sequences are ignored in the lookup. Information about such subsequences is returned separately. The abstract operation returns a record with a [[locale]] field, whose value is the language tag of the selected locale, which must be an element of availableLocales. If the language tag of the request locale that led to the selected locale contained a Unicode locale extension sequence, then the returned record also contains an [[extension]] field whose value is the first Unicode locale extension sequence, and an [[extensionIndex]] field whose value is the index of the first Unicode locale extension sequence within the request locale language tag.
The BestFitMatcher abstract operation compares requestedLocales, which must be a List as returned by CanonicalizeLocaleList, against the locales in availableLocales and determines the best available language to meet the request. The algorithm is implementation dependent, but should produce results that a typical user of the requested locales would perceive as at least as good as those produced by the LookupMatcher abstract operation. Options specified through Unicode locale extension sequences must be ignored by the algorithm. Information about such subsequences is returned separately. The abstract operation returns a record with a [[locale]] field, whose value is the language tag of the selected locale, which must be an element of availableLocales. If the language tag of the request locale that led to the selected locale contained a Unicode locale extension sequence, then the returned record also contains an [[extension]] field whose value is the first Unicode locale extension sequence, and an [[extensionIndex]] field whose value is the index of the first Unicode locale extension sequence within the request locale language tag.
The ResolveLocale abstract operation compares a BCP 47 language priority list requestedLocales against the locales in availableLocales and determines the best available language to meet the request. availableLocales and requestedLocales must be provided as List values, options as a Record.
The following steps are taken:
"lookup"
, then
"-"
."length"
."-u"
."length"
."0"
.""
."-"
, key,
"-"
, and value."true"
."true"
.""
.NOTE Non-normative summary: Two algorithms are available to match the locales: the Lookup algorithm described in RFC 4647 section 3.4, and an implementation dependent best-fit algorithm. Independent of the locale matching algorithm, options specified through Unicode locale extension sequences are negotiated separately, taking the caller’s relevant extension keys and locale data as well as client-provided options into consideration. The abstract operation returns a record with a [[locale]] field whose value is the language tag of the selected locale, and fields for each key in relevantExtensionKeys providing the selected value for that key.
The LookupSupportedLocales abstract operation returns the subset of the provided BCP 47 language priority list requestedLocales for which availableLocales has a matching locale when using the BCP 47 Lookup algorithm. Locales appear in the same order in the returned list as in requestedLocales. The following steps are taken:
The BestFitSupportedLocales abstract operation returns the subset of the provided BCP 47 language priority list requestedLocales for which availableLocales has a matching locale when using the Best Fit Matcher algorithm. Locales appear in the same order in the returned list as in requestedLocales. The steps taken are implementation dependent.
The SupportedLocales abstract operation returns the subset of the provided BCP 47 language priority list requestedLocales for which availableLocales has a matching locale. Two algorithms are available to match the locales: the Lookup algorithm described in RFC 4647 section 3.4, and an implementation dependent best-fit algorithm. Locales appear in the same order in the returned list as in requestedLocales. The following steps are taken:
"localeMatcher"
."lookup"
or "best fit"
, then throw a RangeError
exception."best fit"
, then
The GetOption abstract operation extracts the value of the property named property from the provided options object, converts it to the required type, checks whether it is one of a List of allowed values, and fills in a fallback value if necessary.
"boolean"
or "string"
."boolean"
, then let value be ToBoolean(value)."string"
, then let value be ToString(value).The GetNumberOption abstract operation extracts a property value from the provided options object, converts it to a Number value, checks whether it is in the allowed range, and fills in a fallback value if necessary.
The Intl.Collator constructor is a standard built-in property of the Intl object. Behaviour common to all service constructor properties of the Intl object is specified in 9.1.
The abstract operation InitializeCollator accepts the arguments collator (which must be an object), locales, and options. It initializes collator as a Collator object.
Several steps in the algorithm use values from the following table, which associates Unicode locale extension keys, property names, types, and allowable values:
Key | Property | Type | Values |
---|---|---|---|
kn | numeric | "boolean" | |
kf | caseFirst | "string" | "upper", "lower", "false" |
The following steps are taken:
new Object()
where Object
is the standard built-in constructor with that name."usage"
, "string"
, a List containing the two String values "sort"
and "search"
, and
"sort"
."sort"
, then let localeData be the value of the [[sortLocaleData]] internal
property of Collator; else let localeData be the value of the [[searchLocaleData]] internal property
of Collator."localeMatcher"
, "string"
, a List containing the two
String values "lookup"
and "best fit"
, and "best fit"
."boolean"
and value is not
undefined, then
"length"
."co"
, then
"collation"
."default"
."boolean"
, then let value be the
result of comparing value with "true"
."sensitivity"
, "string"
, a List containing the four
String values "base"
, "accent"
, "case"
, and "variant"
, and
undefined."sort"
, then let s be "variant"
."sensitivity"
."ignorePunctuation"
, "boolean"
, undefined, and false.When Intl.Collator
is called as a function rather than as a constructor, it accepts the optional arguments
locales and options and takes the following steps:
Intl.Collator(locales,
options)
, where Intl.Collator
is the standard built-in constructor defined in 10.1.3.When Intl.Collator
is called as part of a new
expression, it is a constructor: it initializes
the newly created object.
The [[Prototype]] internal property of the newly constructed object is set to the original Intl.Collator prototype
object, the one that is the initial value of Intl.Collator.prototype
(10.2.1).
The [[Extensible]] internal property of the newly constructed object is set to true.
Collator-specific properties of the newly constructed object are set using the following steps:
Besides the internal properties and the length
property (whose value is 0), the Intl.Collator constructor has
the following properties:
The value of Intl.Collator.prototype
is the built-in Intl.Collator prototype object (10.3).
This property has the attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false }.
When the supportedLocalesOf
method of Intl.Collator is called, the following steps are taken:
The value of the length
property of the supportedLocalesOf
method is 1
.
The value of the [[availableLocales]] internal property is implementation defined within the constraints described in 9.1.
The value of the [[relevantExtensionKeys]] internal property is an array that must include the element "co"
,
may include any or all of the elements "kn"
and "kf"
, and must not include any other elements.
NOTE Unicode Technical Standard 35 describes ten locale extension keys that are relevant to collation: "co" for collator usage and specializations, "ka" for alternate handling, "kb" for backward second level weight, "kc" for case level, "kn" for numeric, "kh" for hiragana quaternary, "kk" for normalization, "kf" for case first, "kr" for reordering, "ks" for collation strength, and "vt" for variable top. Collator, however, requires that the usage is specified through the usage property of the options object, alternate handling through the ignorePunctuation property of the options object, and case level and the strength through the sensitivity property of the options object. The "co" key in the language tag is supported only for collator specializations, and the keys "kb", "kh", "kk", "kr", and "vt" are not allowed in this version of the Internationalization API. Support for the remaining keys is implementation dependent.
The values of the [[sortLocaleData]] and [[searchLocaleData]] internal properties are implementation defined within the constraints described in 9.1 and the following additional constraints:
The first element of [[sortLocaleData]][locale].co and [[searchLocaleData]][locale].co must be null for all locale values.
The values "standard"
and "search"
must not be used as elements in any
[[sortLocaleData]][locale].co and [[searchLocaleData]][locale].co array.
[[searchLocaleData]][locale] must have a sensitivity property with a String value equal to "base"
,
"accent"
, "case"
, or "variant"
for all locale values.
The Intl.Collator prototype object is itself an Intl.Collator instance as specified in 10.4, whose
internal properties are set as if it had been constructed by the expression Intl.Collator.call({})
with the
standard built-in values of Intl.Collator and Function.prototype.call.
In the following descriptions of functions that are properties or [[Get]] attributes of properties of the Intl.Collator prototype object, the phrase “this Collator object” refers to the object that is the this value for the invocation of the function; a TypeError exception is thrown if the this value is not an object or an object that does not have an [[initializedCollator]] internal property with value true.
The initial value of Intl.Collator.prototype.constructor
is the built-in Intl.Collator constructor.
This named accessor property returns a function that compares two strings according to the sort order of this Collator object.
The value of the [[Get]] attribute is a function that takes the following steps:
NOTE The function returned by [[Get]] is bound to this Collator object so that it can be passed directly to Array.prototype.sort or other functions.
The value of the [[Set]] attribute is undefined.
When the CompareStrings abstract operation is called with arguments collator (which must be an object initialized as a Collator), x and y (which must be String values), it returns a Number other than NaN that represents the result of a locale-sensitive String comparison of x with y. The two Strings are compared in an implementation-defined fashion. The result is intended to order String values in the sort order specified by the effective locale and collation options computed during construction of collator, and will be negative, zero, or positive, depending on whether x comes before y in the sort order, the Strings are equal under the sort order, or x comes after y in the sort order, respectively. String values must be interpreted as UTF-16 code unit sequences, and a surrogate pair (a code unit in the range 0xD800 to 0xDBFF followed by a code unit in the range 0xDC00 to 0xDFFF) within a string must be interpreted as the corresponding code point.
The sensitivity of collator is interpreted as follows:
base: Only strings that differ in base letters compare as unequal. Examples: a ≠ b, a = á, a = A.
accent: Only strings that differ in base letters or accents and other diacritic marks compare as unequal. Examples: a ≠ b, a ≠ á, a = A.
case: Only strings that differ in base letters or case compare as unequal. Examples: a ≠ b, a = á, a ≠ A.
variant: Strings that differ in base letters, accents and other diacritic marks, or case compare as unequal. Other differences may also be taken into consideration. Examples: a ≠ b, a ≠ á, a ≠ A.
NOTE In some languages, certain letters with diacritic marks are considered base letters. For example, in Swedish, “ö” is a base letter that’s different from “o”.
If the collator is set to ignore punctuation, then strings that differ only in punctuation compare as equal.
For the interpretation of options settable through extension keys, see Unicode Technical Standard 35.
The CompareStrings abstract operation with any given collator argument, if considered as a function of the remaining two arguments x and y, must be a consistent comparison function (as defined in ES5, 15.4.4.11) on the set of all Strings.
The actual return values are implementation-defined to permit implementers to encode additional information in the value. The method is required to return 0 when comparing Strings that are considered canonically equivalent by the Unicode standard.
NOTE 1 It is recommended that the CompareStrings abstract operation be implemented following Unicode Technical Standard 10, Unicode Collation Algorithm (available at http://unicode.org/reports/tr10/), using tailorings for the effective locale and collation options of collator. It is recommended that implementations use the tailorings provided by the Common Locale Data Repository (available at http://cldr.unicode.org/).
NOTE 2 Applications should not assume that the behaviour of the CompareStrings abstract operation for Collator instances with the same resolved options will remain the same for different versions of the same implementation.
This function provides access to the locale and collation options computed during initialization of the object.
The function returns a new object whose properties and attributes are set as if constructed by an object literal assigning to each of the following properties the value of the corresponding internal property of this Collator object (see 10.4): locale, usage, sensitivity, ignorePunctuation, collation, as well as those properties shown in Table 1 whose keys are included in the [[relevantExtensionKeys]] internal property of the standard built-in object that is the initial value of Intl.Collator.
Intl.Collator instances inherit properties from the Intl.Collator prototype object. Their [[Class]] internal property value
is "Object"
.
Intl.Collator instances and other objects that have been successfully initialized as a Collator have [[initializedIntlObject]] and [[initializedCollator]] internal properties whose values are true.
Objects that have been successfully initialized as a Collator also have several internal properties that are computed by the constructor:
[[locale]] is a String value with the language tag of the locale whose localization is used for collation.
[[usage]] is one of the String values "sort"
or "search"
, identifying the collator usage.
[[sensitivity]] is one of the String values "base"
, "accent"
, "case"
, or
"variant"
, identifying the collator’s sensitivity.
[[ignorePunctuation]] is a Boolean value, specifying whether punctuation should be ignored in comparisons.
[[collation]] is a String value with the “type” given in Unicode Technical Standard 35 for the collation, except that
the values "standard"
and "search"
are not allowed, while the value "default"
is
allowed.
Objects that have been successfully initialized as a Collator also have the following internal properties if the key corresponding to the name of the internal property in Table 1 is included in the [[relevantExtensionKeys]] internal property of Intl.Collator:
[[numeric]] is a Boolean value, specifying whether numeric sorting is used.
[[caseFirst]] is a String value; allowed values are specified in Table 1.
Finally, objects that have been successfully initialized as a Collator have a [[boundCompare]] internal property that caches the function returned by the compare accessor (10.3.2).
The NumberFormat constructor is a standard built-in property of the Intl object. Behaviour common to all service constructor properties of the Intl object is specified in 9.1.
The abstract operation InitializeNumberFormat accepts the arguments numberFormat (which must be an object), locales, and options. It initializes numberFormat as a NumberFormat object.
The following steps are taken:
new Object()
where Object
is the standard built-in constructor with that name."localeMatcher"
, "string"
,
a List containing the two String values "lookup"
and "best fit"
, and
"best fit"
."style"
, "string"
, a List containing the three String
values "decimal"
, "percent"
, and "currency"
, and "decimal"
."currency"
, "string"
, undefined, and undefined."currency"
and c is undefined, throw a TypeError exception."currency"
, then
"currencyDisplay"
, "string"
, a List containing the
three String values "code"
, "symbol"
, and "name"
, and
"symbol"
."currency"
, then set the [[currencyDisplay]] internal property of numberFormat to
cd."minimumIntegerDigits"
, 1, 21, and
1."currency"
, then let mnfdDefault be cDigits; else let mnfdDefault
be 0."minimumFractionDigits"
, 0, 20, and mnfdDefault."currency"
, then let mxfdDefault be max(mnfd, cDigits); else if
s is "percent"
, then let mxfdDefault be max(mnfd, 0); else let mxfdDefault
be max(mnfd, 3)."maximumFractionDigits"
, mnfd, 20, and mxfdDefault."minimumSignificantDigits"
."maximumSignificantDigits"
."minimumSignificantDigits"
, 1, 21, and 1."maximumSignificantDigits"
, mnsd, 21, and 21."useGrouping"
, "boolean"
, undefined, and true."patterns"
."positivePattern"
."negativePattern"
.When the CurrencyDigits abstract operation is called with an argument currency (which must be an upper case String value), the following steps are taken:
When Intl.NumberFormat
is called as a function rather than as a constructor, it accepts the optional
arguments locales and options and takes the following steps:
new Intl.NumberFormat(locales,
options)
, where Intl.NumberFormat
is the standard built-in constructor defined in 11.1.3.When Intl.NumberFormat
is called as part of a new
expression, it is a constructor: it
initializes the newly created object.
The [[Prototype]] internal property of the newly constructed object is set to the original Intl.NumberFormat prototype
object, the one that is the initial value of Intl.NumberFormat.prototype
(11.2.1).
The [[Extensible]] internal property of the newly constructed object is set to true.
NumberFormat-specific properties of the newly constructed object are set using the following steps:
Besides the internal properties and the length
property (whose value is 0), the Intl.NumberFormat constructor
has the following properties:
The value of Intl.NumberFormat.prototype
is the built-in Intl.NumberFormat prototype object (11.3).
This property has the attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false }.
When the supportedLocalesOf
method of Intl.NumberFormat is called, the following steps are taken:
The value of the length
property of the supportedLocalesOf
method is 1
.
The value of the [[availableLocales]] internal property is implementation defined within the constraints described in 9.1.
The value of the [[relevantExtensionKeys]] internal property is ["nu"]
.
NOTE Unicode Technical Standard 35 describes two locale extension keys that are relevant to number formatting, "nu" for numbering system and "cu" for currency. Intl.NumberFormat, however, requires that the currency of a currency format is specified through the currency property in the options objects.
The value of the [[localeData]] internal property is implementation defined within the constraints described in 9.1 and the following additional constraints:
The array that is the value of the "nu" property of any locale property of [[localeData]] must not include the values "native", "traditio", or "finance".
[[localeData]][locale] must have a patterns property for all locale values. The value of this property must be an
object, which must have properties with the names of the three number format styles: "decimal"
,
"percent"
, and "currency"
. Each of these properties in turn must be an object with the
properties positivePattern and negativePattern. The value of these properties must be string values that contain a
substring "{number}"
; the values within the currency property must also contain a substring
"{currency}"
. The pattern strings must not contain any characters in the General Category “Number, decimal
digit” as specified by the Unicode Standard.
NOTE It is recommended that implementations use the locale data provided by the Common Locale Data Repository (available at http://cldr.unicode.org/).
The Intl.NumberFormat prototype object is itself an Intl.NumberFormat instance as specified in 11.4, whose internal properties are set as if it had been constructed by the expression
Intl.NumberFormat.call({})
with the standard built-in values of Intl.NumberFormat and
Function.prototype.call.
In the following descriptions of functions that are properties or [[Get]] attributes of properties of the Intl.NumberFormat prototype object, the phrase “this NumberFormat object” refers to the object that is the this value for the invocation of the function; a TypeError exception is thrown if the this value is not an object or an object that does not have an [[initializedNumberFormat]] internal property with value true.
The initial value of Intl.NumberFormat.prototype.constructor
is the built-in Intl.NumberFormat
constructor.
This named accessor property returns a function that formats a number according to the effective locale and the formatting options of this NumberFormat object.
The value of the [[Get]] attribute is a function that takes the following steps:
NOTE The function returned by [[Get]] is bound to this NumberFormat object so that it can be passed directly to Array.prototype.map or other functions.
The value of the [[Set]] attribute is undefined.
When the FormatNumber abstract operation is called with arguments numberFormat (which must be an object initialized as a NumberFormat) and x (which must be a Number value), it returns a String value representing x according to the effective locale and the formatting options of numberFormat.
The computations rely on String values and locations within numeric strings that are dependent upon the implementation and the effective locale of numberFormat (“ILD”) or upon the implementation, the effective locale, and the numbering system of numberFormat (“ILND”). The ILD and ILND Strings mentioned, other than those for currency names, must not contain any characters in the General Category “Number, decimal digit” as specified by the Unicode Standard.
NOTE It is recommended that implementations use the locale data provided by the Common Locale Data Repository (available at http://cldr.unicode.org/).
The following steps are taken:
"."
, then replace it with an ILND String representing the decimal
separator."{number}"
within result with n."currency"
, then:
"code"
, then let
cd be currency."symbol"
,
then let cd be an ILD string representing currency in short form. If the implementation does not
have such a representation of currency, then use currency itself."name"
, then
let cd be an ILD string representing currency in long form. If the implementation does not have such
a representation of currency, then use currency itself."{currency}"
within result with cd.When the ToRawPrecision abstract operation is called with arguments x (which must be a finite non-negative number), minPrecision, and maxPrecision (both must be integers between 1 and 21) the following steps are taken:
"0"
."0"
."."
,
and the remaining p–(e+1) characters of m."0."
, –(e+1) occurrences of the character
"0"
, and the string m."."
, and maxPrecision > minPrecision, then
"0"
:
"."
, then
When the ToRawFixed abstract operation is called with arguments x (which must be a finite non-negative number), minInteger (which must be an integer between 1 and 21), minFraction, and maxFraction (which must be integers between 0 and 20) the following steps are taken:
"0"
. Otherwise, let m be the String consisting of the
digits of the decimal representation of n (in order, with no leading zeroes)."0"
."0"
:
"."
, then
"0"
.Numbering System | Digits |
---|---|
arab | U+0660 to U+0669 |
arabext | U+06F0 to U+06F9 |
bali | U+1B50 to U+1B59 |
beng | U+09E6 to U+09EF |
deva | U+0966 to U+096F |
fullwide | U+FF10 to U+FF19 |
gujr | U+0AE6 to U+0AEF |
guru | U+0A66 to U+0A6F |
hanidec | U+3007, U+4E00, U+4E8C, U+4E09, U+56DB, U+4E94, U+516D, U+4E03, U+516B, U+4E5D |
khmr | U+17E0 to U+17E9 |
knda | U+0CE6 to U+0CEF |
laoo | U+0ED0 to U+0ED9 |
latn | U+0030 to U+0039 |
limb | U+1946 to U+194F |
mlym | U+0D66 to U+0D6F |
mong | U+1810 to U+1819 |
mymr | U+1040 to U+1049 |
orya | U+0B66 to U+0B6F |
tamldec | U+0BE6 to U+0BEF |
telu | U+0C66 to U+0C6F |
thai | U+0E50 to U+0E59 |
tibt | U+0F20 to U+0F29 |
This function provides access to the locale and formatting options computed during initialization of the object.
The function returns a new object whose properties and attributes are set as if constructed by an object literal assigning to each of the following properties the value of the corresponding internal property of this NumberFormat object (see 11.4): locale, numberingSystem, style, currency, currencyDisplay, minimumIntegerDigits, minimumFractionDigits, maximumFractionDigits, minimumSignificantDigits, maximumSignificantDigits, and useGrouping. Properties whose corresponding internal properties are not present are not assigned.
Intl.NumberFormat instances inherit properties from the Intl.NumberFormat prototype object. Their [[Class]] internal
property value is "Object"
.
Intl.NumberFormat instances and other objects that have been successfully initialized as a NumberFormat have [[initializedIntlObject]] and [[initializedNumberFormat]] internal properties whose values are true.
Objects that have been successfully initialized as a NumberFormat also have several internal properties that are computed by the constructor:
[[locale]] is a String value with the language tag of the locale whose localization is used for formatting.
[[numberingSystem]] is a String value with the “type” given in Unicode Technical Standard 35 for the numbering system used for formatting.
[[style]] is one of the String values "decimal"
, "currency"
, or "percent"
,
identifying the number format style used.
[[currency]] is a String value with the currency code identifying the currency to be used if formatting with the
"currency"
style. It is only present when [[style]] has the value "currency"
.
[[currencyDisplay]] is one of the String values "code"
, "symbol"
, or "name"
,
specifying whether to display the currency as an ISO 4217 alphabetic currency code, a localized currency symbol, or a
localized currency name if formatting with the "currency"
style. It is only present when [[style]] has the
value "currency"
.
[[minimumIntegerDigits]] is a non-negative integer Number value indicating the minimum integer digits to be used. Numbers will be padded with leading zeroes if necessary.
[[minimumFractionDigits]] and [[maximumFractionDigits]] are non-negative integer Number values indicating the minimum and maximum fraction digits to be used. Numbers will be rounded or padded with trailing zeroes if necessary.
[[minimumSignificantDigits]] and [[maximumSignificantDigits]] are positive integer Number values indicating the minimum and maximum fraction digits to be shown. Either none or both of these properties are present; if they are, they override minimum and maximum integer and fraction digits – the formatter uses however many integer and fraction digits are required to display the specified number of significant digits.
[[useGrouping]] is a Boolean value indicating whether a grouping separator should be used.
[[positivePattern]] and [[negativePattern]] are String values as described in 11.2.3.
Finally, objects that have been successfully initialized as a NumberFormat have a [[boundFormat]] internal property that caches the function returned by the format accessor (11.3.2).
The Intl.DateTimeFormat constructor is a standard built-in property of the Intl object. Behaviour common to all service constructor properties of the Intl object is specified in 9.1.
The abstract operation InitializeDateTimeFormat accepts the arguments dateTimeFormat (which must be an object), locales, and options. It initializes dateTimeFormat as a DateTimeFormat object.
Several DateTimeFormat algorithms use values from the following table, which provides property names and allowable values for the components of date and time formats:
Property | Values |
---|---|
weekday | "narrow", "short", "long" |
era | "narrow", "short", "long" |
year | "2-digit", "numeric" |
month | "2-digit", "numeric", "narrow", "short", "long" |
day | "2-digit", "numeric" |
hour | "2-digit", "numeric" |
minute | "2-digit", "numeric" |
second | "2-digit", "numeric" |
timeZoneName | "short", "long" |
The following steps are taken:
"any"
, and "date"
."localeMatcher"
, "string"
, a
List containing the two String values "lookup"
and "best fit"
, and
"best fit"
."timeZone"
."UTC"
, then throw a RangeError exception."string"
, a List containing the strings given in the Values column of the row, and undefined."formats"
."formatMatcher"
, "string"
, a List containing the two
String values "basic"
and "best fit"
, and "best fit"
."basic"
, then
"hour12"
, "boolean"
, undefined, and undefined."hour12"
."hourNo0"
."pattern12"
."pattern"
."pattern"
.When the ToDateTimeOptions abstract operation is called with arguments options, required, and defaults, the following steps are taken:
"date"
or "any"
, then
"weekday"
, "year"
, "month"
,
"day"
:
"time"
or "any"
, then
"hour"
, "minute"
, "second"
:
"date"
or "all"
, then
"year"
, "month"
, "day"
:
"numeric"
, [[Writable]]: true, [[Enumerable]]: true,
[[Configurable]]: true}, and false."time"
or "all"
, then
"hour"
, "minute"
, "second"
:
"numeric"
, [[Writable]]: true, [[Enumerable]]: true,
[[Configurable]]: true}, and false.When the BasicFormatMatcher abstract operation is called with two arguments options and formats, the following steps are taken:
["2-digit", "numeric", "narrow", "short", "long"]
.When the BestFitFormatMatcher abstract operation is called with two arguments options and formats, it performs implementation dependent steps, which should return a set of component representations that a typical user of the selected locale would perceive as at least as good as the one returned by BasicFormatMatcher.
When Intl.DateTimeFormat
is called as a function rather than as a constructor, it accepts the optional
arguments locales and options and takes the following steps:
Intl.DateTimeFormat(locales,
options)
, where Intl.DateTimeFormat
is the standard built-in constructor defined in 12.1.3.When Intl.DateTimeFormat
is called as part of a new
expression, it is a constructor: it
initializes the newly created object.
The [[Prototype]] internal property of the newly constructed object is set to the original Intl.DateTimeFormat
prototype object, the one that is the initial value of Intl.DateTimeFormat.prototype
(12.2.1).
The [[Extensible]] internal property of the newly constructed object is set to true.
DateTimeFormat-specific properties of the newly constructed object are set using the following steps:
Besides the internal properties and the length
property (whose value is 0), the Intl.DateTimeFormat
constructor has the following properties:
The value of Intl.DateTimeFormat.prototype
is the built-in Intl.DateTimeFormat prototype object (12.3).
This property has the attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false }.
When the supportedLocalesOf
method of Intl.DateTimeFormat is called, the following steps are taken:
The value of the length
property of the supportedLocalesOf
method is 1
.
The value of the [[availableLocales]] internal property is implementation defined within the constraints described in 9.1.
The value of the [[relevantExtensionKeys]] internal property is ["ca", "nu"]
.
NOTE Unicode Technical Standard 35 describes three locale extension keys that are relevant to date and time formatting, "ca" for calendar, "tz" for time zone, and implicitly "nu" for the numbering system of the number format used for numbers within the date format. DateTimeFormat, however, requires that the time zone is specified through the timeZone property in the options objects.
The value of the [[localeData]] internal property is implementation defined within the constraints described in 9.1 and the following additional constraints:
The array that is the value of the "nu" property of any locale property of [[localeData]] must not include the values "native", "traditio", or "finance".
[[localeData]][locale] must have hour12 and hourNo0 properties with Boolean values for all locale values.
[[localeData]][locale] must have a formats property for all locale values. The value of this property must be an array of objects, each of which has a subset of the properties shown in Table 3, where each property must have one of the values specified for the property in Table 3. Multiple objects in an array may use the same subset of the properties as long as they have different values for the properties. The following subsets must be available for each locale:
Each of the objects must also have a pattern property, whose value is a String value that contains for each of the date and time format component properties of the object a substring starting with "{", followed by the name of the property, followed by "}". If the object has an hour property, it must also have a pattern12 property, whose value is a String value that, in addition to the substrings of the pattern property, contains a substring "{ampm}".
EXAMPLE An implementation might include the following object as part of its English locale data: {hour: "numeric", minute: "2-digit", second: "2-digit", pattern: "{hour}:{minute}:{second}", pattern12: "{hour}:{minute}:{second} {ampm}"}.
NOTE It is recommended that implementations use the locale data provided by the Common Locale Data Repository (available at http://cldr.unicode.org/).
The Intl.DateTimeFormat prototype object is itself an Intl.DateTimeFormat instance as specified in 12.4, whose internal properties are set as if it had been constructed by the expression
Intl.DateTimeFormat.call({})
with the standard built-in values of Intl.DateTimeFormat and
Function.prototype.call.
In the following descriptions of functions that are properties or [[Get]] attributes of properties of the Intl.DateTimeFormat prototype object, the phrase “this DateTimeFormat object” refers to the object that is the this value for the invocation of the function; a TypeError exception is thrown if the this value is not an object or an object that does not have an [[initializedDateTimeFormat]] internal property with value true.
The initial value of Intl.DateTimeFormat.prototype.constructor
is the built-in Intl.DateTimeFormat
constructor.
This named accessor property returns a function that formats a date according to the effective locale and the formatting options of this DateTimeFormat object.
The value of the [[Get]] attribute is a function that takes the following steps:
Date.now()
where Date.now
is the standard built-in function defined in ES5, 15.9.4.4.NOTE The function returned by [[Get]] is bound to this DateTimeFormat object so that it can be passed directly to Array.prototype.map or other functions.
The value of the [[Set]] attribute is undefined.
When the FormatDateTime abstract operation is called with arguments dateTimeFormat (which must be an object initialized as a DateTimeFormat) and x (which must be a Number value), it returns a String value representing x (interpreted as a time value as specified in ES5, 15.9.1.1) according to the effective locale and the formatting options of dateTimeFormat.
new
Intl.NumberFormat([locale], {useGrouping: false})
where Intl.NumberFormat
is the standard built-in
constructor defined in 11.1.3.new
Intl.NumberFormat([locale], {minimumIntegerDigits: 2, useGrouping: false})
where Intl.NumberFormat
is the standard built-in constructor defined in 11.1.3."year"
and v ≤ 0, then let v be 1 - v."month"
, then increase v by 1."hour"
and the value of the [[hour12]] internal property of dateTimeFormat
is true, then
"numeric"
, then
"2-digit"
, then
"narrow"
, "short"
, or "long"
, then let fv be
a String value representing f in the desired form; the String value depends upon the implementation and
the effective locale and calendar of dateTimeFormat. If p is "month"
, then the
String value may also depend on whether dateTimeFormat has a [[day]] internal property. If p is
"timeZoneName"
, then the String value may also depend on the value of the [[inDST]] field of
tm."{"
, p, and "}"
, with
fv."{ampm}"
, with fv.NOTE It is recommended that implementations use the locale and calendar dependent strings provided by the Common Locale Data Repository (available at http://cldr.unicode.org/), and use CLDR “abbreviated” strings for DateTimeFormat “short” strings, and CLDR “wide” strings for DateTimeFormat “long” strings.
When the ToLocalTime abstract operation is called with arguments date, calendar, and timeZone, the following steps are taken:
"gregory"
, then the calculations must match the algorithms
specified in ES5, 15.9.1, except that
calculations are not bound by the restrictions on the use of best available information on time zones for local time
zone adjustment and daylight saving time adjustment imposed by ES5, 15.9.1.7 and 15.9.1.8.NOTE It is recommended that implementations use the time zone information of the IANA Time Zone Database.
This function provides access to the locale and formatting options computed during initialization of the object.
The function returns a new object whose properties and attributes are set as if constructed by an object literal assigning to each of the following properties the value of the corresponding internal property of this DateTimeFormat object (see 12.4): locale, calendar, numberingSystem, timeZone, hour12, weekday, era, year, month, day, hour, minute, second, and timeZoneName. Properties whose corresponding internal properties are not present are not assigned.
NOTE In this version of the ECMAScript Internationalization API, the timeZone property will remain undefined if no timeZone property was provided in the options object provided to the Intl.DateTimeFormat constructor. However, applications should not rely on this, as future versions may return a String value identifying the host environment’s current time zone instead.
Intl.DateTimeFormat instances inherit properties from the Intl.DateTimeFormat prototype object. Their [[Class]] internal
property value is "Object"
.
Intl.DateTimeFormat instances and other objects that have been successfully initialized as a DateTimeFormat have [[initializedIntlObject]] and [[initializedDateTimeFormat]] internal properties whose values are true.
Objects that have been successfully initialized as a DateTimeFormat also have several internal properties that are computed by the constructor:
[[locale]] is a String value with the language tag of the locale whose localization is used for formatting.
[[calendar]] is a String value with the “type” given in Unicode Technical Standard 35 for the calendar used for formatting.
[[numberingSystem]] is a String value with the “type” given in Unicode Technical Standard 35 for the numbering system used for formatting.
[[timeZone]] is either the String value "UTC"
or undefined.
[[weekday]], [[era]], [[year]], [[month]], [[day]], [[hour]], [[minute]], [[second]], [[timeZoneName]] are each either absent, indicating that the component is not used for formatting, or one of the String values given in Table 3, indicating how the component should be presented in the formatted output.
[[hour12]] is a Boolean value indicating whether 12-hour format (true) or 24-hour format (false) should be used. It is only present when [[hour]] is also present.
[[hourNo0]] is a Boolean value indicating whether hours from 1 to 12 (true) or from 0 to 11 (false) should be used. It is only present when [[hour12]] is also present and has the value true.
[[pattern]] is a String value as described in 12.2.3.
Finally, objects that have been successfully initialized as a DateTimeFormat have a [[boundFormat]] internal property that caches the function returned by the format accessor (12.3.2).
The ECMAScript Language Specification, edition 5.1 or successor, describes several locale sensitive functions. An ECMAScript implementation that implements this Internationalization API shall implement these functions as described here.
NOTE The Collator, NumberFormat, or DateTimeFormat objects created in the algorithms in this clause are only used within these algorithms. They are never directly accessed by ECMAScript code and need not actually exist within an implementation.
This definition supersedes the definition provided in ES5, 15.5.4.9.
When the localeCompare
method is called with argument that and optional arguments
locales, and options, the following steps are taken:
new Intl.Collator(locales,
options)
where Intl.Collator
is the standard built-in constructor defined in 10.1.3.The value of the length
property of the localeCompare
method is 1
.
NOTE 1 The localeCompare
method itself is not directly suitable as an argument to
Array.prototype.sort
because the latter requires a function of two arguments.
NOTE 2 The localeCompare
function is intentionally generic; it does not require
that its this value be a String object. Therefore, it can be transferred to other kinds of objects for use as a
method.
This definition supersedes the definition provided in ES5, 15.7.4.3.
When the toLocaleString
method is called with optional arguments locales and options,
the following steps are taken:
new
Intl.NumberFormat(locales, options)
where Intl.NumberFormat
is the standard built-in constructor
defined in 11.1.3.The value of the length
property of the toLocaleString
method is 0
.
This definition supersedes the definition provided in ES5, 15.9.5.5.
When the toLocaleString
method is called with optional arguments locales and options,
the following steps are taken:
"Invalid Date"
."any"
, and
"all"
.new
Intl.DateTimeFormat(locales, options)
where Intl.DateTimeFormat
is the standard built-in
constructor defined in 12.1.3.The value of the length
property of the toLocaleString
method is 0
.
This definition supersedes the definition provided in ES5, 15.9.5.6.
When the toLocaleDateString
method is called with optional arguments locales and
options, the following steps are taken:
"Invalid Date"
."date"
, and
"date"
.new
Intl.DateTimeFormat(locales, options)
where Intl.DateTimeFormat
is the standard built-in
constructor defined in 12.1.3.The value of the length
property of the toLocaleDateString
method is 0
.
This definition supersedes the definition provided in ES5, 15.9.5.7.
When the toLocaleTimeString
method is called with optional arguments locales and
options, the following steps are taken:
"Invalid Date"
."time"
, and
"time"
.new
Intl.DateTimeFormat(locales, options)
where Intl.DateTimeFormat
is the standard built-in
constructor defined in 12.1.3.The value of the length
property of the toLocaleTimeString
method is 0
.
The following aspects of the ECMAScript Internationalization API are implementation dependent:
In all functionality:
In Collator:
"co"
key values (collations) per locale beyond a default collation (10.2.3)"kn"
key values (numeric collation) per locale (10.2.3)"kf"
key values (case order) per locale (10.2.3)In NumberFormat:
"nu"
key values (numbering systems) per locale (11.2.3)In DateTimeFormat:
"ca"
key values (calendars) per locale (12.2.3)"nu"
key values (numbering systems) per locale (12.2.3)"gregory"
, and adjustments for local time
zones and daylight saving time (12.3.2)