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.

I'm using macOS and found that Chrome's navigator.languages reflects the browser language setting while Intl.DateTimeFormat().resolvedOptions().locale reflects the OS language setting. Don't know if this is also the case in other OSs.