What controls the date format for a locale in Intl.DateTimeFormat?

Question

What specification or body controls what date formats are used for locales in Intl.DateTimeFormat?

E.g. What was the process/decision/body that specified that the en-CA date format is 'm/d/yyyy' but the fr-CA one yyyy-mm-dd?

Is there a public standard document I can consume for my own purposes?

Answer 1

Each browser or JS engine determines the internationalization (i18n) formats for each locale.

Per § 21.4.4.38:

21.4.4.38 Date.prototype.toLocaleDateString([reserved1 [, reserved2]])

This method returns a String value. The contents of the String are implementation-defined, but are intended to represent the "date" portion of the Date in the current time zone in a convenient, human-readable form that corresponds to the conventions of the host environment's current locale.

What does Google use?

In this case, Google V8 implementation of the ECMAScript standard defines its own rules that govern the format of dates for a given locale.

I am not sure where Google stores their i18n data for each locale; but according to this Stack Overflow comment, the Unicode CLDR project has been a reliable source for formats. This repository is now archived, but it has been moved to https://github.com/unicode-org/cldr-json.

Note: The V8 developer website states that that Unicode CLDR is the source for Intl.RelativeTimeFormat. Also, after viewing the i18n support page, it looks like V8 requires ICU version 63 at compile time. I have noticed that the V8 mirror on GitHub gets updated from time to time to bump the ICU version.

What's amusing is that the preferred English Canadian format is y-MM-dd, but Google's implementation must be using the alternative variant.

• en-CA/ca-gregorian.json (line 327)
  • main['en-CA'].dates.calendars.gregorian.dateFormats['short-alt-variant'] → d/M/yy
• fr-CA/ca-gregorian.json (line 314)
  • main['fr-CA'].dates.calendars.gregorian.dateFormats.short → y-MM-dd

Unicode CLDR

After some further investigation, the alternative variant was added between versions 28.0.0 and 29.0.0. This occurred in the last quarter of 2015 and the first quarter of 2016.

Version 28.0.0

• Dated: 17 September 2015
• Tag: https://github.com/unicode-cldr/cldr-dates-modern/releases/tag/28.0.0
• See: https://github.com/unicode-cldr/cldr-dates-modern/blob/28.0.0/main/en-CA/ca-gregorian.json#L327

{
  "dateFormats": {
    "full": "EEEE, MMMM d, y",
    "long": "MMMM d, y",
    "medium": "MMM d, y",
    "short": "y-MM-dd"
  }
}

Version 29.0.0

• Dated: 17 March 2016
• Tag: https://github.com/unicode-cldr/cldr-dates-modern/releases/tag/29.0.0
• See: https://github.com/unicode-cldr/cldr-dates-modern/blob/29.0.0/main/en-CA/ca-gregorian.json#L327

{
 "dateFormats": {
    "full": "EEEE, MMMM d, y",
    "long": "MMMM d, y",
    "medium": "MMM d, y",
    "short": "y-MM-dd",
    "short-alt-variant": "d/M/yy"
  }
}

Note: The latest version of this code now lives in (unicode-org):

https://github.com/unicode-org/cldr-json/blob/main/cldr-json/cldr-dates-modern/main/en-CA/ca-gregorian.json

date-fns

According to date-fns, their preferred format is yyyy-MM-dd.

See: https://github.com/date-fns/date-fns/blob/v2.29.3/src/locale/en-CA/_lib/formatLong/index.ts#L8

const dateFormats = {
  full: 'EEEE, MMMM do, yyyy',
  long: 'MMMM do, yyyy',
  medium: 'MMM d, yyyy',
  short: 'yyyy-MM-dd',
}

Summary

As you can see, each engine or library determines how it implements i18n formats for each locale. Furthermore, these formats evolve and change over time. If you have any questions regarding the format for a given locale, defer to the Unicode CLDR Project.

Answer 2

It's a bug in the Unicode database which has been rolled out during Feb 2023 by automatic updates to Chrome, Edge, Firefox and presumably other browsers, though not Safari at the moment.

refs:

• https://github.com/unicode-org/cldr/blame/main/common/main/en_CA.xml#L1184
• https://unicode-org.atlassian.net/browse/CLDR-16399 which in turns references the bug in the chromium project

The JS standard says to use CLDR: “Note 3: It is recommended that implementations use the locale data provided by the Common Locale Data Repository (available at https://cldr.unicode.org/).”