TO_CHAR函数将时间转为字符串，需用大写格式代码（如YYYY、MM、MI、HH24）；TIMESTAMPTZ会按数据库时区转换，时区调整须用AT TIME ZONE；中文输出不稳定，推荐CASE+EXTRACT；避免在WHERE中使用以防索引失效。
TO_CHAR函数的基本用法和模板字符串规则
TO_CHAR 是 PostgreSQL 中把时间值转为字符串的核心函数，它不改变数据本身，只控制显示格式。关键在于第二个参数——模板字符串，它不是正则表达式，也不是任意字符组合，而是由预定义的格式化代码（如 YYYY、MM、DD、HH24、MI、SS）和字面量拼接而成。
常见错误是直接写 'yyyy-mm-dd hh:mm:ss'，结果分钟变成 hh:mm:ss 里的 mm 被解释为“月份”，输出变成类似 2024-05-15 14-05-22（第二个 05 是五月，不是分钟）。正确写法必须用大写的格式代码：
SELECT TO_CHAR(NOW(), 'YYYY-MM-DD HH24:MI:SS');
-
YYYY：4位年份；YY是2位，但易歧义，不建议 -
MM：月份（01–12），MI才是分钟（00–59） -
HH24：24小时制（00–23）；HH12配合AM/PM使用 - 字面量（如连字符、冒号、空格）需原样写出，无需转义
处理时区偏移与带时区的时间戳
如果字段类型是 TIMESTAMP WITH TIME ZONE（即 TIMESTAMPTZ），TO_CHAR 默认按数据库当前时区（timezone 参数值）转换后再格式化。想显式指定时区输出，不能靠模板代码，而要先用 AT TIME ZONE 调整：
SELECT TO_CHAR(NOW() AT TIME ZONE 'Asia/Shanghai', 'YYYY-MM-DD HH24:MI:SS');
- 模板中
OF可输出时区偏移（如+08），OFT输出带冒号的（如+08:00） -
TZ和TZD分别输出时区缩写（如CST）和带夏令时标识的缩写（如CDT），但依赖系统时区数据库，不可靠 - 若源数据是
TIMESTAMP WITHOUT TIME ZONE，TO_CHAR不做任何时区转换，直接按输入值格式化
中文星期、月份等本地化输出的坑
PostgreSQL 的 TO_CHAR 支持本地化，但效果高度依赖操作系统 locale 设置和数据库集群初始化时的 --locale 参数。即使设置了 lc_time = 'zh_CN.UTF-8'，也可能因底层 C 库缺失对应翻译而 fallback 到英文。
常用中文格式代码：DAY（星期全名）、DY（星期缩写）、MONTH（月份全名）、MON（月份缩写）。但实测中：
-
TO_CHAR(NOW(), 'DAY')可能返回'MONDAY '（右补空格到 9 字符），不是'星期一' - 真正稳定输出中文的方法是用
CASE+EXTRACT拼接，例如：SELECT CASE EXTRACT(DOW FROM NOW())::INT<br> WHEN 0 THEN '星期日'<br> WHEN 1 THEN '星期一'<br> -- ...<br>END;
- 依赖
lc_time的方式只适合内部报表且可控部署环境，上线前务必在目标服务器上验证
性能影响与替代方案考量
TO_CHAR 是纯计算型函数，对单行无明显开销，但在 WHERE 或 ORDER BY 中滥用会导致索引失效——比如 WHERE TO_CHAR(created_at, 'YYYY-MM') = '2024-05' 无法走 created_at 上的 B-tree 索引。
- 日期范围查询优先用原生比较：
created_at >= '2024-05-01' AND created_at - 如需高频格式化展示，考虑在应用层做（Python 的
strftime、JavaScript 的toLocaleString），减轻数据库压力 - 若必须数据库端生成固定格式且查询频繁，可建函数索引：
CREATE INDEX idx_created_yyyymm ON logs ((TO_CHAR(created_at, 'YYYY-MM')));
最常被忽略的一点：模板字符串里多一个空格、少一个冒号，错误不会报语法错，而是静默输出不符合预期的结果——调试时务必用已知确定值（如 TO_CHAR('2024-05-15 14:30:45'::TIMESTAMP, '...')）逐段验证。
