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该干的事。
