PostgreSQL的TO_TIMESTAMP解析时间字符串需严格匹配毫秒位数（用MS而非US）、手动处理ISO格式中的T/Z及时区、预转换中文格式为标准格式，并通过表达式索引优化性能。
TO_TIMESTAMP解析带毫秒但无时区的时间字符串
PostgreSQL的TO_TIMESTAMP对毫秒支持很直接，但容易忽略小数点位数必须严格匹配格式串。比如'2023-10-05 14:23:18.123'不能用'YYYY-MM-DD HH24:MI:SS.US'——US代表微秒（6位），而.123只有3位毫秒，会导致解析失败或截断为.123000再被当成微秒处理，结果时间偏移。
正确做法是：用MS（毫秒，3位）对应.123，或统一补零后用US。示例：
SELECT TO_TIMESTAMP('2023-10-05 14:23:18.123', 'YYYY-MM-DD HH24:MI:SS.MS');
- 若输入可能含2位或4位小数，先用
REGEXP_REPLACE标准化为3位（如'.12'→'.120'，'.1234'→'.123'） -
MS只认前3位数字，多余位会被丢弃，不四舍五入 - 该格式不自动附加时区，返回的是
timestamp without time zone，后续需显式AT TIME ZONE转换
解析ISO 8601变体（如"T"分隔、无空格、带Z）
标准ISO格式如'2023-10-05T14:23:18Z'或'2023-10-05T14:23:18.123+08:00'不能直接用TO_TIMESTAMP——它不识别T字面量和Z，也不解析+08:00时区偏移。
必须拆解处理：
SELECT TO_TIMESTAMP(
REPLACE(REPLACE('2023-10-05T14:23:18Z', 'T', ' '), 'Z', ''),
'YYYY-MM-DD HH24:MI:SS'
) AT TIME ZONE 'UTC';
- 对含
+HH:MM的字符串，先用正则提取时区部分，再用substring()切分时间主体与偏移 -
TO_TIMESTAMP本身不支持T或Z占位符，硬写进格式串会报错invalid value for format element - 如果原始字符串时区已知且固定（如全为UTC），优先用
AT TIME ZONE而非尝试在TO_TIMESTAMP里塞时区逻辑
解析中文或本地化格式（如“2023年10月5日 14:23:18”）
PostgreSQL默认不识别中文年月日关键字，TO_TIMESTAMP会把“年”“月”“日”当作字面量匹配，一旦输入缺字（如漏“日”）就报错time field value out of range。
安全做法是预处理：用TRANSLATE或REPLACE转成英文或纯数字格式：
SELECT TO_TIMESTAMP(
TRANSLATE('2023年10月5日 14:23:18', '年月日', '-/-'),
'YYYY-MM-DD HH24:MI:SS'
);
- 避免依赖
lc_time区域设置——它影响的是月份/星期名称，不解决“年月日”这类结构词 - 如果输入格式不稳定（有时带“日”，有时不带），先用
REGEXP_REPLACE统一补全，例如'(\d{4})年(\d{1,2})月(\d{1,2})日?'→'\1-\2-\3' - 中文数字（如“二〇二三年”）必须先转阿拉伯数字，
TO_TIMESTAMP完全不识别Unicode数字字符
性能与批量转换注意事项
在WHERE或JOIN条件中高频调用TO_TIMESTAMP会显著拖慢查询，尤其配合函数索引失效时。它无法利用普通B-tree索引，且每次调用都触发字符串解析开销。
- 对固定格式的列，建表达式索引：
CREATE INDEX idx_ts ON logs ((TO_TIMESTAMP(event_time, 'YYYY-MM-DD HH24:MI:SS'))); - 避免在
ORDER BY中嵌套TO_TIMESTAMP，应提前物化为timestamp列或用CASE预判格式分支 - 当存在多种非标格式混存（如同时有
MS和US精度），用CASE WHEN ... THEN TO_TIMESTAMP(...) END比盲目试错更可控，但注意NULL传播逻辑
真正麻烦的不是语法怎么写，而是同一字段里混着不同格式、不同精度、不同时区标识——这种数据得先清洗再进库，别指望TO_TIMESTAMP兜底。
