将日期时间列加载至Snowflake时出现10/11小时时差问题咨询

可能的核心原因 #

• 时区处理不一致
  Snowflake当前会话时区为UTC-8（从current_timestamp结果2022-11-15 23:46:47.318 -0800可看出），而本地时间对应UTC+2/UTC+1（与Snowflake时间差11/10小时）。若ETL工具（Data Services）合并生成的INVOICEDATE未指定时区，Snowflake会默认按会话时区（UTC-8）解析存储；而STAGE_DATE是源时区（如欧洲中部时间CET/CEST）的时间，二者时区不匹配就会产生时差。

• 夏令时（DST）切换影响
  10和11小时的差值恰好对应夏令时切换前后的时区偏移变化。如果源数据的时间覆盖了夏令时切换节点（比如每年3月最后一个周日、10月最后一个周日前后），STAGE_DATE按带夏令时的本地时区解析，而INVOICEDATE在ETL或Snowflake中未正确处理夏令时规则，就会出现两种不同的差值。

• ETL合并逻辑的时区漏洞
  检查Data Services合并VBRK_FKDAT（日期）和VBRK_ERZET（时间）的过程：是否合并后的INVOICEDATE被错误标记为无时区数据，或在转换为Snowflake兼容格式时丢失了时区元信息，导致Snowflake按会话时区强制转换。

• Snowflake字段类型设置问题
  确认Snowflake表中INVOICEDATE的字段类型：

  • 若为TIMESTAMP_LTZ（本地时区），会自动转换为会话时区（UTC-8）存储；
  • 若为TIMESTAMP_NTZ（无时区），则直接按字面存储，但计算时差时会默认用会话时区解析，与STAGE_DATE的源时区产生偏差。

排查步骤 #

1. 确认源数据VBRK_FKDAT和VBRK_ERZET所属的原始时区（比如欧洲中部时间Europe/Berlin）。
2. 检查Data Services中INVOICEDATE的输出设置：是否明确指定了时区属性，还是以无时区的datetime格式传递给Snowflake。
3. 查看Snowflake的会话时区和字段类型：
   • 执行SELECT CURRENT_TIMEZONE();确认当前会话时区；
   • 执行DESCRIBE TABLE your_table;查看INVOICEDATE的字段类型。
4. 统一时区后验证差值：
   将STAGE_DATE和INVOICEDATE转换为同一时区后计算小时差，比如：

   SELECT 
     DATEDIFF(HOUR, 
       TO_TIMESTAMP_TZ(STAGE_DATE, 'YYYY-MM-DD HH24:MI:SS') AT TIME ZONE 'Europe/Berlin', 
       INVOICEDATE AT TIME ZONE 'Europe/Berlin'
     ) AS HOURDIFF
   FROM your_table;
   

   若差值恢复正常，则说明是时区不匹配导致的问题。
5. 核对异常记录的时间点：查看出现10/11小时差的记录是否集中在夏令时切换前后的时间段。

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