sql标准不支持to_char或date_format等时间格式化函数，均为厂商扩展；可移植方案仅cast或应用层处理；postgresql的to_char最可控，但需注意时区、类型转换和性能问题。

SQL标准里没有TO_CHAR或DATE_FORMAT

标准SQL（ISO/IEC 9075）不定义任何时间格式化函数。这意味着TO_CHAR（Oracle/PostgreSQL）、DATE_FORMAT（MySQL）、FORMAT（SQL Server）全是厂商扩展，跨数据库不可移植。如果你写的是“标准SQL脚本”，直接调用这些函数就等于放弃标准兼容性。

真正可移植的做法只有两种：CAST转为DATE/TIMESTAMP类型（丢失精度但无格式控制），或依赖外部应用层处理。标准SQL连EXTRACT都只允许取年/月/日等整数字段，无法拼接成“2024-03-15 14:22:08”这样的字符串。

PostgreSQL中用TO_CHAR最接近“安全转换”

PostgreSQL的TO_CHAR是实践中最可控的时间格式化方案，支持时区、本地化、空值处理，且错误行为明确（如非法模板报ERROR: invalid value for format）。

• 基础用法：SELECT TO_CHAR(NOW(), 'YYYY-MM-DD HH24:MI:SS');
• 带时区：用'TZ'/'TZH:TZM'模板，配合AT TIME ZONE确保源时间戳已归一化
• 避免隐式转换：不要对TEXT列直接TO_CHAR，先CAST(col AS TIMESTAMP)，否则可能触发ERROR: invalid input syntax for type timestamp
• 性能注意：在WHERE子句里用TO_CHAR(ts_col, 'YYYYMM') = '202403'会强制全表扫描——应改用范围查询：ts_col >= '2024-03-01' AND ts_col

MySQL必须用DATE_FORMAT，但要注意默认时区陷阱

MySQL的DATE_FORMAT语法直观，但实际执行受time_zone系统变量影响极大。同一个NOW()在会话时区为+00:00和+08:00下格式化结果一致，但底层时间值不同——如果原始时间戳是UTC存储，而会话时区是本地，则DATE_FORMAT(NOW(), '%Y-%m-%d')返回的是本地日期，不是UTC日期。

• 安全做法：显式转换时区再格式化，例如DATE_FORMAT(CONVERT_TZ(NOW(), @@session.time_zone, '+00:00'), '%Y-%m-%d %H:%i:%s')
• 模板字符区分大小写：%Y是4位年，%y是2位；%H是24小时制，%h是12小时制
• NULL输入返回NULL，不会报错，但容易掩盖数据问题——建议前置WHERE ts_col IS NOT NULL

跨数据库方案只能靠应用层或生成SQL

真要写一次代码适配多库，别在SQL里硬扛格式化。更现实的路径是：

• 数据库只返回TIMESTAMP WITH TIME ZONE或UTC毫秒数，由Java/Python/JS做最终格式化
• 用ORM（如SQLAlchemy、Django ORM）的func.to_char等方言接口，按dialect自动切换函数名
• 若必须拼SQL，用模板引擎（Jinja2、Handlebars）根据dialect == 'postgresql'条件注入不同函数调用

强行统一SQL写法只会让你在某个数据库上突然发现TO_CHAR不存在，或者DATE_FORMAT不接受'YYYY'这种Oracle风格模板——时间格式化从来就不是SQL该干的事。