Redshift向表插入timestamp类型数据时自动转为date类型问题

• 转换逻辑隐性生成了无差异时间分量的timestamp值
  table1的period_start本身是date类型，执行to_date(period_start,'YYYY-MM-DD HH24:MI:SS')时，date类型会先被隐式转成YYYY-MM-DD格式的字符串，转date后再cast为timestamp，默认时间分量为00:00:00.000，视觉上和date值完全一致。另外第二个字段的计算全程基于date类型运算，部分数仓（如Redshift）对date转timestamp的毫秒精度处理存在兼容问题，也可能导致时间分量被自动取整到零点。
• 查询客户端展示配置问题
  绝大多数SQL查询工具默认会省略展示timestamp类型中00:00:00格式的时间分量，仅显示日期部分，容易让用户误以为存储的是date类型，实际底层存储结构仍是timestamp。
• 建表语法错误导致字段类型未生效
  你提供的建表语句中，第一个字段前多写了一个逗号，部分数据库兼容语法会跳过错误字段，自动用默认的date类型创建同名字段，也会导致该问题。

1. 先验证实际字段存储类型，执行以下语句确认table2的字段定义：

SELECT column_name, data_type 
FROM information_schema.columns 
WHERE table_name = 'table2' 
AND column_name IN ('period_start', 'period_end');

如果返回的data_type是timestamp，说明是显示或转换逻辑问题，否则是建表异常，需要重新建表。
2. 修正建表语法（如果存在异常），去掉多余的逗号：

CREATE TABLE IF NOT EXISTS table2
(
    period_start timestamp   ENCODE zstd,
    period_end timestamp   ENCODE zstd
)

3. 修正插入语句的转换逻辑，避免隐性类型转换：

insert into table2 (period_start ,period_end)
select 
    -- 直接将date转timestamp，省略多余的to_date操作
    period_start::timestamp, 
    -- 先转timestamp再做毫秒级计算，避免date类型截断精度
    DATEADD(millisecond, -1, (last_day(period_start + 75) + 1)::timestamp)
from table1;

4. 查询时强制格式化输出，展示完整timestamp内容：

SELECT 
    to_char(period_start, 'YYYY-MM-DD HH24:MI:SS.MS') AS period_start_full,
    to_char(period_end, 'YYYY-MM-DD HH24:MI:SS.MS') AS period_end_full
FROM table2;

内容的提问来源于stack exchange，提问作者Itay