MySQL GET_FORMAT 怎样为日期选择地区格式模板

我在做日期字段展示时，最容易把“地区格式”与“语言本地化”混在一起。MySQL 的 GET_FORMAT() 解决的是前者：根据 DATE、TIME、DATETIME（或按 DATETIME 处理的 TIMESTAMP）和一个模板名，返回可交给日期函数使用的格式字符串。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/date-and-time-functions.html

最稳妥的用法是先确定数据类型，再从 USA、EUR、JIS、ISO、INTERNAL 中选模板；展示用 DATE_FORMAT()，字符串转日期用 STR_TO_DATE()。它不会把月份名称自动翻译成某种语言。

先把“地区”理解成格式，不是语言

GET_FORMAT(type, format) 返回的是格式模板。例如 GET_FORMAT(DATE, 'USA') 返回 %m.%d.%Y，GET_FORMAT(DATE, 'EUR') 返回 %d.%m.%Y。JIS 与 ISO 在 DATE 场景都返回 %Y-%m-%d，而 INTERNAL 返回紧凑的 %Y%m%d。

我会先画出类型与模板的边界，再决定是否把结果交给展示或解析函数。这样做的好处是，格式选择不会散落在多条 SQL 字符串里。

用 GET_FORMAT 取得可复用的格式字符串

下面的查询把常用模板放在一起，适合先确认团队约定。代码中的注释只解释每个查询块的用途，不把返回值伪装成运行截图。

-- DATE 适合只关心年月日的报表字段
SELECT
  GET_FORMAT(DATE, 'USA') AS usa_date,
  GET_FORMAT(DATE, 'EUR') AS eur_date,
  GET_FORMAT(DATE, 'ISO') AS iso_date,
  GET_FORMAT(DATE, 'INTERNAL') AS internal_date;

-- TIME 只保留时间部分；USA 会带 12 小时制和 AM/PM
SELECT
  GET_FORMAT(TIME, 'USA') AS usa_time,
  GET_FORMAT(TIME, 'JIS') AS jis_time;

-- DATETIME 同时包含日期和时间，适合事件记录
SELECT GET_FORMAT(DATETIME, 'ISO') AS iso_datetime;

官方文档列出的核心结果是：DATE 的 USA/EUR/JIS/ISO/INTERNAL 分别对应 %m.%d.%Y、%d.%m.%Y、%Y-%m-%d、%Y-%m-%d、%Y%m%d；DATETIME 的 ISO 是 %Y-%m-%d %H:%i:%s；TIME 的 USA 是 %h:%i:%s %p。如果第二个参数是 NULL，函数也返回 NULL。

展示日期时，把模板交给 DATE_FORMAT

当数据库里的值已经是日期或日期时间，展示层通常需要一个字符串。把模板交给 DATE_FORMAT()，比在业务代码里手写多套格式更容易维护。

-- 用 USA 模板输出月.日.年，格式来源由 GET_FORMAT 统一管理
SELECT DATE_FORMAT(
  '2026-10-30',
  GET_FORMAT(DATE, 'USA')
) AS display_date;

-- ISO 模板适合接口或日志中的固定年月日时分秒
SELECT DATE_FORMAT(
  '2026-10-30 18:20:00',
  GET_FORMAT(DATETIME, 'ISO')
) AS display_datetime;

这里的“USA”只改变数字排列和分隔符，不能让 DATE_FORMAT() 输出英文月份名。月份、星期名称的语言由 lc_time_names 控制，这是另一条配置线，不应和 GET_FORMAT 混为一谈。

解析外部字符串时复用同一份模板

导入 CSV 或接收表单日期时，方向反过来：输入是字符串，目标是得到日期值。此时让 STR_TO_DATE() 使用同一个模板，可以把“外部约定”和“数据库解释方式”绑定在一起。

-- 外部字符串按月.日.年解析为 DATE 语义
SELECT STR_TO_DATE(
  '10.30.2026',
  GET_FORMAT(DATE, 'USA')
) AS parsed_date;

-- 如果外部协议使用紧凑日期，就明确使用 INTERNAL 模板
SELECT STR_TO_DATE(
  '20261030',
  GET_FORMAT(DATE, 'INTERNAL')
) AS parsed_internal_date;

我觉得这个组合最适合放在边界层：输入先按约定解析，内部继续保存日期类型，输出再按调用方需要格式化。不要把格式化后的字符串当成长期存储值，否则排序和日期计算会变得不直观。

几个容易踩到的边界

• ISO 不等于完整 ISO 8601。 MySQL 文档说明这里的 ISO 指 ISO 9075；GET_FORMAT 返回的是日期格式字符串，不会自动带时区或偏移量。
• DATETIME 与 TIMESTAMP 要看任务。 TIMESTAMP 作为第一个参数时，GET_FORMAT 返回与 DATETIME 相同的模板；时区转换仍是另一层问题。
• NULL 要提前处理。 第二个参数为 NULL 时 GET_FORMAT 返回 NULL，继续传给格式化或解析函数时也会得到 NULL 语义。
• 模板只覆盖固定集合。 如果产品需要毫秒、时区、中文年月日或特殊分隔符，应直接维护明确的 DATE_FORMAT 字符串，并为输入输出分别写清契约。

相关问题

GET_FORMAT 能切换月份语言吗？ 不能。它选择数字日期/时间布局；月份和星期名称的语言由 lc_time_names 影响。

DATE_FORMAT 和 STR_TO_DATE 能共用模板吗？ 可以。前者把日期值格式化成字符串，后者按字符串和同一格式模板解析日期，关键是输入样式必须与模板相符。

我的结论是：把 GET_FORMAT 当作“有限的格式模板目录”，先按数据类型选模板，再决定是展示还是解析。这样既能减少重复字符串，也能让地区写法、存储类型和接口边界各自保持清楚。