AI 助理
备案控制台
开发者社区 数据库 文章 正文

夏令时的坑：你的数据库真的能正确处理时间跳变吗？

2025-03-21 22 发布于北京
版权
举报
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介： 时区是地球上使用相同标准时间的区域。由于地球的自转，为了保证各地的时间与当地的日出日落相协调，全球划分为多个时区。

1. 定义

1.1 时区
时区是地球上使用相同标准时间的区域。由于地球的自转，为了保证各地的时间与当地的日出日落相协调，全球划分为多个时区。

1.2 IANA 时区
IANA（Internet Assigned Numbers Authority）时区数据库，也称为 tz database，提供全球时区信息的标准参考。它是现代各类系统和软件处理时区相关操作的基础。
IANA 使用“区域/城市”格式（如 Europe/Berlin）来明确标识时区。
时序数据库 TDengine 在不同组件中均支持使用 IANA 时区（除 Windows taos.cfg 时区设置外）。

1.3 标准时间与当地时间
标准时间是根据地球上某个固定经线确定的时间。它为各个时区提供了一个统一的参考点。

  • 格林尼治标准时间（GMT）：历史上使用的参考时间，位于0°经线。
  • 协调世界时（UTC）：现代的时间标准，类似于GMT，但更加精确。
    标准时间与时区的关系：
  • 基准：标准时间（如 UTC）是时区设定的基准点。
  • 偏移量：不同时区通过相对于标准时间的偏移量来定义。例如，UTC+1表示比 UTC 快 1 小时。
  • 区域划分：全球被划分为多个时区，每个时区使用一个或多个标准时间。
    相对于标准时间，每个地区根据其所在时区设定其当地时间：
  • 时区偏移：当地时间等于标准时间加上该时区的偏移量。例如，UTC+2 表示比 UTC 时间快 2 小时。
  • 夏令时（DST）：某些地区在特定时间段调整当地时间，例如将时钟拨快一小时。详见下节。

1.4 夏令时
夏令时（Daylight Saving Time，DST）是一种通过将时间提前一小时，以充分利用日光、节约能源的制度。通常在春季开始，秋季结束。夏令时的具体开始和结束时间因地区而异。以下均以柏林时间为例，对夏令时和夏令时的影响做说明。

dd2f75ec18c62545251e1c3e3331f1e4__fallback_source=1&height=1280&mount_node_token=doxcn1XRlzJBTnio50KQas1p4Gd&mount_point=docx_image&policy=equal&width=1280.png

按照这个规则，可以看到：

  • 柏林当地时间 2024 年 3 月 31 日 02:00:00 到 03:00:00 （不含 03:00:00）之间的时间不存在（跳变）。
  • 柏林当地时间 2024 年 10 月 27 日 02:00:00 到 03:00:00 （不含 03:00:00）之间的时间出现了两次。

夏令时与 IANA 时区数据库

  • 记录规则：IANA 时区数据库详细记录了各地的夏令时规则，包括开始和结束的日期与时间。
  • 自动调整：许多操作系统和软件利用 IANA 数据库来自动处理夏令时的调整。
  • 历史变更：IANA 数据库还追踪历史上的夏令时变化，以确保准确性。

夏令时与时间戳转换

  • 时间戳转为当地时间是确定的。例如，1729990654 为柏林时间 夏令时 2024-10-27 02:57:34，1729994254 为柏林时间 冬令时 2024-10-27 02:57:34 （这两个本地时间除时间偏移量外是一样的）。
  • 不指定时间偏移量时，当地时间转为时间戳是不确定的。夏令时跳过的时间不存在会造成无法转换成时间戳，如 柏林时间 2024-03-31 02:34:56 不存在，所以无法转换为时间戳。夏令时结束时重复导致无法确定是哪个时间戳，如 2024-10-27 02:57:34 不指定时间偏移量无法确定 是 1729990654 还是 1729994254。指定时间偏移量才能确定时间戳，如 2024-10-27 02:57:34 CEST(+02:00) ，指定了夏令时 2024-10-27 02:57:34 时间戳 1729990654 。

1.5 RFC3339 时间格式

RFC 3339 是一种互联网时间格式标准，用于表示日期和时间。它基于 ISO 8601 标准，但更具体地规定了一些格式细节。
其格式如下：

  • 基本格式：YYYY-MM-DDTHH:MM:SSZ
  • 时区表示：
    • Z 表示协调世界时（UTC）。
    • 偏移量格式，例如 +02:00，表示与 UTC 的时差。
      通过明确的时区偏移，RFC 3339 格式可以在全球范围内准确地解析和比较时间。
      RFC 3339 的优势：
  • 标准化：提供统一的格式，方便跨系统数据交换。
  • 清晰性：明确时区信息，避免时间误解。
    TDengine 在 REST API 和 Explorer UI 中，均使用 RFC3339 格式进行展示。在 SQL 语句中，可使用 RFC3339 格式写入时间戳数据：
    ` sinsert into t1 values('2024-10-27T01:59:59.000Z', 0); select * from t1 where ts >= '2024-10-27T01:59:59.000Z';

1.6 未定义行为

未定义行为（Undefined Behavior）是指特定代码或操作没有明确规定的结果，也不会对该结果作出兼容性的保证。在 TDengine 中，用户不可依赖当前未定义的行为进行判断或应用。

2. 夏令时在 TDengine 中的写入与查询

我们使用下表来展示夏令时在写入和查询中的影响。
QQ截图20250321145002.jpg
2.1 表头说明

  • TIMESTAMP：TDengine 中使用 64位整数来存储原始时间戳。
  • UTC：时间戳对应的 UTC 时间表示。
  • Europe/Berlin：表示时区 Europe/Berlin 对应的 RFC3339 格式时间。
  • Local：表示时区 Europe/Berlin 对应的当地时间（不含时区）。

2.2 表格分析

  • 在夏令时开始（柏林时间 3月31日 02:00 ）时，时间直接从 02:00 跳到 03:00（往后跳一小时）。
    • 浅绿色是夏令时开始前一小时的时间戳；
    • 深绿色是夏令时开始后一小时的时间戳；
    • 红色为 TDengine 数据库中插入了不存在的当地时间：
      • 使用 SQL INSERT INTO t1 values('2024-03-31 02:59:59',..) 插入 2024-03-31 02:00:00 到 2024-03-31 02:59:59 的数据会被自动调整为 -1000（在 TDengine 中属于未定义行为，当前该值与数据库精度 precision 有关，毫秒数据库为 -1000，微秒数据库为 -1000000，纳秒数据库为 -1000000000），因为那一时刻在本地时间中不存在；
  • 在夏令时结束（柏林时间 10 月 27 日 03:00）时，时间从 03:00 跳到 02:00 （往前跳一小时）。
    • 浅蓝色表示时钟跳变前一小时的时间戳；
    • 深蓝色表示时钟跳变后一小时内的时间戳，其无时区的当地时间与上一小时一致。
    • 紫色表示时钟跳变一小时后的时间戳；
  • 当地时间变化：可见，由于夏令时的调整而导致了当地时间的变化，可能导致某些时间段出现重复或缺失。
  • UTC时间不变：UTC 时间保持不变，确保了时间的一致性和顺序性。
  • RFC3339：RFC3339 格式时间显示了时间偏移量的变化，在夏令时开始后变为 +02:00，结束后变为 +01:00 。
  • 条件查询：
    • 夏令时开始时，跳过的时间（[03-31 02:00:00,03-31 03:00:00)）不存在，所以在使用该时间进行查询时，行为不确定：SELECT ts FROM t1 WHERE ts BETWEEN '2024-03-31 02:00:00' AND '2024-03-31 02:59:59' （不存在的本地时间戳被转换为 -1000）:
      taos> SELECT ts FROM t1 WHERE ts BETWEEN '2024-03-31 02:00:00' AND  '2024-03-31 02:59:59';
   ts       |
=================
-1000 |
Query OK, 1 row(s) in set (0.003635s)

      
        
      
          
        
      
        
        
      
          
      
          AI 代码解读
      当不存在的时间戳与存在的时间戳共同使用时，其结果同样不符合预期，以下为起始本地时间不存在：

taos> SELECT ts, to_iso8601(ts,'Z') FROM t1 WHERE ts BETWEEN '2024-03-31 02:00:00' AND '2024-03-31 03:59:59'; ts | to_iso8601(ts,'Z') |================================================== -1000 | 1969-12-31T23:59:59.000Z | 1711843200000 | 2024-03-31T00:00:00.000Z | 1711846799000 | 2024-03-31T00:59:59.000Z | 1711846800000 | 2024-03-31T01:00:00.000Z | 1711846801000 | 2024-03-31T01:00:01.000Z | Query OK, 5 row(s) in set (0.003339s)

以下语句中第一个 SQL 查询截止时间不存在，第二个截止时间存在，第一个 SQL 查询结果不符合预期：

 taos> SELECT ts, to_iso8601(ts,'Z') FROM t1 WHERE ts BETWEEN '2024-03-31 01:00:00' AND  '2024-03-31 02:00:00';
Query OK, 0 row(s) in set (0.000930s)

taos> SELECT ts, to_iso8601(ts,'Z') FROM t1 WHERE ts BETWEEN '2024-03-31 01:00:00' AND  '2024-03-31 01:59:59';
       ts       |       to_iso8601(ts,'Z')       |
==================================================
 1711843200000 | 2024-03-31T00:00:00.000Z       |
 1711846799000 | 2024-03-31T00:59:59.000Z       |
Query OK, 2 row(s) in set (0.001227s)


        

          
        

        
        

          

          AI 代码解读
  • 夏令时结束时，跳变的时间（[10-27 02:00:00,10-27 03:00:00) 不包含 10-27 03:00:00）重复了两次，TDengine 在使用该区间内的时间戳进行查询时，也属于未定义行为。
    • 查询 [2024-10-27 02:00:00, 2024-10-27 03:00:00] 之间的数据结果，包含了两次重复的时间戳和 2024-10-27 03:00:00 这个时间点的数据：
taos> SELECT ts, to_iso8601(ts,'Z'), TO_CHAR(ts, 'YYYY-MM-DD HH:mi:ss') FROM t1 WHERE ts BETWEEN '2024-10-27 02:00:00' AND  '2024-10-27 03:00:00';
       ts       |       to_iso8601(ts,'Z')       | to_char(ts, 'YYYY-MM-DD HH:mi:ss') |
=======================================================================================
 1729987200000 | 2024-10-27T00:00:00.000Z       | 2024-10-27 02:00:00                |
 1729990799000 | 2024-10-27T00:59:59.000Z       | 2024-10-27 02:59:59                |
 1729990800000 | 2024-10-27T01:00:00.000Z       | 2024-10-27 02:00:00                |
 1729994399000 | 2024-10-27T01:59:59.000Z       | 2024-10-27 02:59:59                |
 1729994400000 | 2024-10-27T02:00:00.000Z       | 2024-10-27 03:00:00                |
Query OK, 5 row(s) in set (0.001370s)


        

          
        

        
        

          

          AI 代码解读
  • 但以下查询 [2024-10-27 02:00:00.000,2024-10-27 02:57:34.999] 区间只能查询到第一个2024-10-27 02:00:00 时间点的数据：
taos> SELECT ts, to_iso8601(ts,'Z'), TO_CHAR(ts, 'YYYY-MM-DD HH:mi:ss') FROM t1 WHERE ts >= '2024-10-27 02:00:00' AND ts <= '2024-10-27 02:57:00.999';
       ts       |       to_iso8601(ts,'Z')       | to_char(ts, 'YYYY-MM-DD HH:mi:ss') |
=======================================================================================
 1729987200000 | 2024-10-27T00:00:00.000Z       | 2024-10-27 02:00:00                |
Query OK, 1 row(s) in set (0.004480s)


        

          
        

        
        

          

          AI 代码解读
  • 以下查询 [2024-10-27 02:00:01,2024-10-27 02:57:35] 却能查到 3 条数据（包含一条 02:59:59 的当地时间数据）：
taos> SELECT ts, to_iso8601(ts,'Z'), TO_CHAR(ts, 'YYYY-MM-DD HH:mi:ss') FROM t1 WHERE ts >= '2024-10-27 02:00:00' AND ts <= '2024-10-27 02:57:35';;
           ts            |       to_iso8601(ts,'Z')       | to_char(ts, 'YYYY-MM-DD HH:mi:ss') |
================================================================================================
 2024-10-27 02:00:00.000 | 2024-10-27T00:00:00.000Z       | 2024-10-27 02:00:00                |
 2024-10-27 02:59:59.000 | 2024-10-27T00:59:59.000Z       | 2024-10-27 02:59:59                |
 2024-10-27 02:00:00.000 | 2024-10-27T01:00:00.000Z       | 2024-10-27 02:00:00                |
Query OK, 3 row(s) in set (0.004428s)


        

          
        

        
        

          

          AI 代码解读

3. 总结与建议

3.1 总结
仅针对使用当地时间带来的影响作说明，使用 UNIX 时间戳或 RFC3339 无影响。

  • 写入：
    • 无法写入夏令时跳变时不存在的时间数据。
    • 写入夏令时跳变时重复的时间是未定义行为。
  • 查询：
    • 查询条件指定夏令时开始时跳变的时间，其查询结果为未定义行为。
    • 查询条件指定夏令时结束时重复的时间，其查询结果为未定义行为。
  • 显示：
    • 带时区显示不受影响。
    • 显示当地时间是准确的，但夏令时结束时重复的时间会无法区分。
    • 用户应谨慎使用不带时区的时间进行展示和应用。

3.2 建议
为避免夏令时给查询和写入造成不必要的影响，在 TDengine 中，建议使用明确的时间偏移量进行写入和查询。

  • 使用 UNIX 时间戳：使用 UNIX 时间戳可避免时区问题。
    QQ截图20250321151604.jpg
taos> insert into t1 values(1711846799000, 1)(1711846800000, 2);
Insert OK, 2 row(s) affected (0.001434s)

taos> select * from t1 where ts between 1711846799000 and 1711846800000;
       ts       |     v1      |
===============================
 1711846799000 |           1 |
 1711846800000 |           2 |
Query OK, 2 row(s) in set (0.003503s)


        

          
        

        
        

          

          AI 代码解读
  • 使用 RFC3339 时间格式：带时区偏移量的 RFC3339 时间格式可以有效避免夏令时的不确定性。
    QQ截图20250321151707.jpg
taos> insert into t1 values ('2024-10-27T02:00:00.000+02:00', 1)
                            ('2024-10-27T02:59:59.000+02:00', 2)
                            ('2024-10-27T02:00:00.000+01:00', 3)
                            ('2024-10-27T02:59:59.000+01:00', 4);
Insert OK, 4 row(s) affected (0.001514s)

taos> SELECT *,
             to_iso8601(ts,'Z'),
             to_char(ts, 'YYYY-MM-DD HH:mi:ss') FROM t1
      WHERE ts >= '2024-10-27T02:00:00.000+02:00'
        AND ts <= '2024-10-27T02:59:59.000+01:00';
       ts      |     v1  |       to_iso8601(ts,'Z')       | to_char(ts, 'YYYY-MM-DD HH:mi:ss') |
=====================================================================================================
 1729987200000 |       1 | 2024-10-27T00:00:00.000Z       | 2024-10-27 02:00:00                |
 1729990799000 |       2 | 2024-10-27T00:59:59.000Z       | 2024-10-27 02:59:59                |
 1729990800000 |       3 | 2024-10-27T01:00:00.000Z       | 2024-10-27 02:00:00                |
 1729994399000 |       4 | 2024-10-27T01:59:59.000Z       | 2024-10-27 02:59:59                |
Query OK, 4 row(s) in set (0.004275s)

taos> SELECT *,
             to_iso8601(ts,'Z'),
             to_char(ts, 'YYYY-MM-DD HH:mi:ss') FROM t1
      WHERE ts >= '2024-10-27T02:00:00.000+02:00'
        AND ts <= '2024-10-27T02:59:59.000+02:00';
       ts      |     v1  |       to_iso8601(ts,'Z')       | to_char(ts, 'YYYY-MM-DD HH:mi:ss') |
=====================================================================================================
 1729987200000 |       1 | 2024-10-27T00:00:00.000Z       | 2024-10-27 02:00:00                |
 1729990799000 |       2 | 2024-10-27T00:59:59.000Z       | 2024-10-27 02:59:59                |
Query OK, 2 row(s) in set (0.004275s)


        

          
        

        
        

          

          AI 代码解读
  • 查询时注意时区设定：在查询和显示时，如果需要本地时间，务必考虑夏令时的影响。
    • taosAdapter：使用 REST API 时，支持设置 IANA 时区，结果使用 RFC3339 格式返回。
$ curl -uroot:taosdata 'localhost:6041/rest/sql?tz=Europe/Berlin'\
  -d "select ts from tz1.t1"
{"code":0,"column_meta":[["ts","TIMESTAMP",8]],"data":[["1970-01-01T00:59:59.000+01:00"],["2024-03-31T01:00:00.000+01:00"],["2024-03-31T01:59:59.000+01:00"],["2024-03-31T03:00:00.000+02:00"],["2024-03-31T03:00:01.000+02:00"],["2024-10-27T02:00:00.000+02:00"],["2024-10-27T02:59:59.000+02:00"],["2024-10-27T02:00:00.000+01:00"],["2024-10-27T02:59:59.000+01:00"],["2024-10-27T03:00:00.000+01:00"]],"rows":10}


        

          
        

        
        

          

          AI 代码解读
文章标签：
数据库
SQL
Unix
网络架构
API
TDengine
+关注
101文章
目录
打赏
0
0
0
0
93
分享
相关文章
风水道人
|
10月前
|
关系型数据库 MySQL Java
SpringBoor连接mysql数据库取数据库中时间格式是12小时制的时间，如何显示成24小时制
SpringBoor连接mysql数据库取数据库中时间格式是12小时制的时间，如何显示成24小时制
风水道人
110 0
糜终
|
5月前
|
存储 监控 关系型数据库
MySQL计算某条数据与上一条数据的生成时间差
MySQL计算某条数据与上一条数据的生成时间差
糜终
120 2
javaNice
|
10月前
|
关系型数据库 MySQL Serverless
mysql计算时间差 小时差 天数差 分钟差
mysql计算时间差 小时差 天数差 分钟差
javaNice
133 0
赵延东的一亩三分地
|
SQL
【SQL开发实战技巧】系列（十七）：数据仓库中时间类型操作（初级）确定两个日期之间的工作天数、计算—年中周内各日期出现次数、确定当前记录和下一条记录之间相差的天数
如何确定两个日期之间的工作日有多少天、计算—年中每周内各日期出现次数、确定当前记录和下一条记录之间相差的天数【SQL开发实战技巧】这一系列博主当作复习旧知识来进行写作，毕竟SQL开发在数据分析场景非常重要且基础，面试也会经常问SQL开发和调优经验，相信当我写完这一系列文章，也能再有所收获，未来面对SQL面试也能游刃有余~。本章节的三个需求：确定两个日期之间的工作天数、计算—年中周内各日期出现次数、确定当前记录和下一条记录之间相差的天数有些许难度，不过建议还是学会比较好。
赵延东的一亩三分地
221 0
【SQL开发实战技巧】系列（十七）：数据仓库中时间类型操作（初级）确定两个日期之间的工作天数、计算—年中周内各日期出现次数、确定当前记录和下一条记录之间相差的天数
17863961702
|
数据库
mybaits传入的时间参数与数据库实际插入的时间晚8个小时
mybaits传入的时间参数与数据库实际插入的时间晚8个小时
17863961702
245 0
mybaits传入的时间参数与数据库实际插入的时间晚8个小时
Z2O安全攻防
|
NoSQL 关系型数据库 MySQL
MySQL时间盲注五种延时方法
MySQL时间盲注五种延时方法
Z2O安全攻防
556 0
NineData
|
SQL 弹性计算 运维
数据库故障致美国超一万航班取消或延迟
在2023年新年的第二周，美国东部时间1月11日上午，6点29分，美国航空监管机构（FAA）发布了一条仅40字的通告，随后不久，很快就宣布停飞全美所有国内航班。通告内容是，FAA正在对NOTAM（Notice to Air Missions）系统进行验证和恢复，在第一条通知之后的50分钟，FAA就宣布停飞所有国内航班。
NineData
392 0
数据库故障致美国超一万航班取消或延迟
心城以北
|
Java
记录一次时间戳、夏令时、时区线上问题分析
记录一次时间戳、夏令时、时区线上问题分析
心城以北
710 0
记录一次时间戳、夏令时、时区线上问题分析
javaedge
|
关系型数据库 MySQL 数据库
备库为什么会延迟好几个小时？（下）
为什么要有多线程复制呢？这是因为单线程复制的能力全面低于多线程复制，对于更新压力较大的主库，备库是可能一直追不上主库的。从现象上看就是，备库上seconds_behind_master的值越来越大。 在介绍完每个并行复制策略后，我还和你分享了不同策略的优缺点： 如果你是DBA，就需要根据不同的业务场景，选择不同的策略； 如果是你业务开发人员，也希望你能从中获取灵感用到平时的开发工作中。 从这些分析中，你也会发现大事务不仅会影响到主库，也是造成备库复制延迟的主要原因之一。因此，在平时的开发工作中，我建议你尽量减少大事务操作，把大事务拆成小事务。
javaedge
175 0
备库为什么会延迟好几个小时？（下）
javaedge
|
存储 关系型数据库 MySQL
备库为什么会延迟好几个小时？（上）
为什么要有多线程复制呢？这是因为单线程复制的能力全面低于多线程复制，对于更新压力较大的主库，备库是可能一直追不上主库的。从现象上看就是，备库上seconds_behind_master的值越来越大。 在介绍完每个并行复制策略后，我还和你分享了不同策略的优缺点： 如果你是DBA，就需要根据不同的业务场景，选择不同的策略； 如果是你业务开发人员，也希望你能从中获取灵感用到平时的开发工作中。 从这些分析中，你也会发现大事务不仅会影响到主库，也是造成备库复制延迟的主要原因之一。因此，在平时的开发工作中，我建议你尽量减少大事务操作，把大事务拆成小事务。
javaedge
167 0
备库为什么会延迟好几个小时？（上）

热门文章

最新文章

  • 1
    搭建一个简单的直播网站
    20
  • 2
    VS Code书写vue项目配置 eslint+prettier 统一代码风格
    11
  • 3
    maven checkstyle插件报错
    11
  • 4
    阿里云物联网平台offline离线日志原因排查
    19
  • 5
    日交易笔百万级，Ping++的大数据平台架构
    7
  • 6
    [20180328]不要在sys建立用户对象.txt
    4
  • 7
    java数组拷贝的方法
    3
  • 8
    Linux-(kill,wc,killall,ln,cal,date)
    4
  • 9
    RoboGuice下载和安装
    4
  • 10
    【图】解eclipse 查看原始类出现The jar file rt.jar has no source attachment
    3
  • 1
    【YashanDB 知识库】YAS-04115 "SELECT" expected but missing
    50
  • 2
    【YashanDB知识库】lYAS-02143 invalid username/password, login denied
    30
  • 3
    【YashanDB 知识库】YCM Monit 进程频繁误告警
    30
  • 4
    【YashanDB 知识库】YMP 校验从 yashandb 同步到 oracle 的数据时，字段 timestamp(0) 出现不一致
    28
  • 5
    【YashanDB 知识库】并发 update 报错 YAS-02208 lock conflict in consistent write
    27
  • 6
    【YashanDB 知识库】导入数据时报错：YAS-00008 type convert error：literal does not match format string
    18
  • 7
    【YashanDB 知识库】druid 连接池做断网测试，无法自动重新连接
    21
  • 8
    【YashanDB 知识库】Hive 命令工具 insert 崖山数据库报错
    21
  • 9
    【YashanDB知识库】YMP从mysql迁移到崖山，报错：服务器错误
    20

    • 相关电子书

    更多
  • 低代码开发师（初级）实战教程
  • 冬季实战营第三期：MySQL数据库进阶实战
  • 阿里巴巴DevOps 最佳实践手册
    • 下一篇
    阿里云oss简介和如何对接使用
    目录