Power Query的locale不只是界面语言，日期文本还要经过怎样的解释

经营资料中的一列明明写着日期，Power Query转换后却出现错误，是否就能认定原业务日期不存在？微软的Data types in Power Query文档提供了一个更具体的解释：软件在转换类型之前，要先按相应区域设置理解文本。日期类型名称与文本采用哪种顺序，并不是同一个问题。

文档将locale联系的内容分成两部分。Localization决定界面以什么语言显示；globalization处理值的格式，也参与文本值的解释。Locale把二者放在一个设置值里，因此它不只是把按钮从一种语言翻成另一种语言。资料以English（United States）为例，既联系美国英语，也联系相应的值格式。

理解这一区别，要从原值开始。一个字段被标为Date，只说明准备把它解释为日期类型，并没有自行交代原文字是月在前还是日在前。微软随后用美国与英国日期格式作例子：美国顺序是月、日、年，英国顺序是日、月、年。如果英国格式中的日为22，而解释过程把它放在月份位置，就会遇到不存在第22个月的问题。

这个例子中，错误发生在解释顺序与文本格式之间，不能直接转述成“这一天不存在”。原文本中22可以承担日的角色；把它当作月份，是另一项处理前提。本文只是展开文档例子，没有读取某家企业的日期列，也不能由这个例子诊断所有转换错误都有同样原因。

区域解释的来源又因产品环境而不同。该页说，Power Query Online在项目的Regional settings中定义这种解释；Desktop默认识别操作系统的区域格式，并允许当前文件另有区域设置。因此，一份交接仅写“都用了Power Query”，还没有完整描述日期文本被怎样理解。项目、文件和操作系统在文档中有各自的位置。

转换后的值与画面上怎样显示，也应继续区分。文档在后续说明中把globalization与日期格式联系起来，并讨论分别查看年、月、日的含义。对阅读者而言，显示顺序是一种呈现信息；原文本经历了怎样的解释，则属于值形成的背景。不能只因为画面符合自己的习惯，就省去这段背景。这里不提供菜单或转换步骤。

上述内容采用微软locale连续说明，页面标示2026年8月14日更新，首次日期未知。它不同于列质量覆盖多少行的问题，也不是对报表进行清洗或财税审核。日期文本、解释区域与最终显示分别说明，才能把一个转换错误放回它实际涉及的语义环节。