1

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?

ScottR
  • 3,080
  • 3
  • 32
  • 35
  • Looks like [Canada's government prefers](https://en.wikipedia.org/wiki/Date_and_time_notation_in_Canada#:~:text=The%20Government%20of%20Canada%20recommends,as%20the%20country's%20date%20format.) `YYYY-MM-DD` for both English and French. Apparently [Canadian passports](https://www.quora.com/What-is-the-standard-date-format-for-Canada/answer/Melina-McLarty) display `DD/MM/YYYY`. The latter is an "American" standard. Hence the distinction between `en-CA` (English) and `fr-CA` (French) formats. – Mr. Polywhirl Feb 22 '23 at 18:32
  • See [date format by country](https://en.wikipedia.org/wiki/Date_format_by_country) on Wikipedia for some more information. I assume the committee that publishes ECMAScript standards gets to decide which format is used for each language/country. – Mr. Polywhirl Feb 22 '23 at 18:44
  • I want to know when things change and why. E.g. recently en-CA was changed from YYYY-MM-DD to DD/MM/YYYY and some tests broke because of it. The problem I'm solving is because a client wants to know the context around the change (who controls it, why does it change, how often do changes happen, etc.) – ScottR Feb 22 '23 at 19:35
  • My client noticed the error in our web app last week. I guess the answer to the context question is something like “the international body responsible has introduced a bug into the database and all the major browsers have picked it up this month” ? Hopefully they fix it fast but the CLDR issue is still unassigned after a week. – Chris F Carroll Feb 23 '23 at 10:51

2 Answers2

2

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.

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

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

Version 29.0.0

{
 "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.

Mr. Polywhirl
  • 42,981
  • 12
  • 84
  • 132
  • It's actually an interesting question because I've always (blindly) assumed the formats were correct. And yet this shows that we need to validate the output with the country's official format. Certainly if you were writing software for CA gov you'd want to know this behavior. +1 – Yogi Feb 22 '23 at 19:59
  • 1
    CLDR project seems to be the source - others have found a recent change to be inconsistent with CA gov official formats. https://unicode-org.atlassian.net/browse/CLDR-16399 – ScottR Feb 22 '23 at 22:08
  • In the code, I think the relevant thing is not the adding of the variant in 2016, but the commit of July 2022 which erroneously set the default short date format for en-CA to 'inherit from "en"', ie American format (I looked at main/common/...xml not at the json, not sure how the xml is generated though). So that's the bug we are hoping will get fixed pronto :-( – Chris F Carroll Feb 23 '23 at 12:12
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:

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/).”

Chris F Carroll
  • 11,146
  • 3
  • 53
  • 61