Intl.DateTimeFormat带脚本子标签的区域设置格式化差异咨询

使用Intl.DateTimeFormat创建日期格式化器时，传入en-GB作为区域参数的输出结果，与传入en-Latn-GB的结果存在差异，但传入zh-HK和zh-Hant-HK时输出结果完全一致，需要明确该差异产生的底层原因。

复现场景 #

测试代码如下：

const date = new Date(Date.parse('2020-12-20T03:23:16'));

// 传入英国英语短区域标识
console.log(new Intl.DateTimeFormat('en-GB').format(date));
// 常规预期输出: "20/12/2020"
console.log(new Intl.DateTimeFormat('en-Latn-GB').format(date));
// 实际输出与en-GB存在差异

// 传入香港中文两种区域标识
console.log(new Intl.DateTimeFormat('zh-HK').format(date));
console.log(new Intl.DateTimeFormat('zh-Hant-HK').format(date));
// 以上两者输出完全一致

业务触发背景：流程中先基于en-GB创建Intl.Locale实例，调用maximize()方法补全默认区域属性后，直接取返回值的baseName作为格式化器的区域入参；对en-GB执行maximize操作后，返回的baseName会自动带上脚本标识Latn，即变为en-Latn-GB。目前已有临时规避方案，但需要明确底层逻辑。

• 该差异本质是Unicode CLDR（通用区域数据仓库，所有JS引擎Intl系列API的底层数据源）的区域映射规则不一致，不属于JavaScript API的实现bug：
  • 对于香港中文场景：CLDR中zh-HK的默认脚本配置就是Hant（繁体中文），无论传入不带脚本标识的短码zh-HK，还是显式携带脚本标识的zh-Hant-HK，最终都会匹配到完全相同的本地化配置数据，因此格式化结果没有区别。
  • 对于英国英语场景：CLDR未将en-GB与显式携带Latn（拉丁字母）脚本标识的en-Latn-GB做完全等价的别名绑定。受CLDR历史迭代影响，部分版本的CLDR数据中，en-Latn-GB会匹配到泛化的拉丁系英语通用格式规则，而非en-GB绑定的英国本地日/月/年排序格式，最终导致输出结果出现差异。
• Intl.Locale.maximize()的逻辑是严格遵循Unicode标准的可能子标签补全规则，为短区域码自动补全缺失的脚本、区域字段，该操作本身符合规范，差异来源于CLDR数据层面对部分全量区域标签和短标签的等价映射缺失，属于历史遗留问题。
• 生产环境稳妥处理方案：如果业务不需要强制指定特殊脚本，不要直接将maximize()生成的全标签baseName传入Intl格式化器；如果必须使用补全后的标签，可以提前增加一层归一化逻辑，将已知的等价标签（如en-Latn-GB）映射回通用短标签即可。

内容的提问来源于stack exchange，提问作者blackmamba