datetime模块实战：datetime.now()的陷阱，时区处理

做回测系统，时间就是命根子。我见过太多团队，策略逻辑写得漂漂亮亮，结果回测数据对不上，最后发现是时间戳出了问题。今天咱们就聊聊 datetime.now() 这个看似人畜无害的函数，到底埋了多少坑。

一、datetime.now() 的三大陷阱

先问个问题：你在代码里写过 datetime.now() 吗？写过几次？嗯，我猜大部分人天天都在用。但你知道吗，这个函数在回测系统里就是个定时炸弹。

陷阱1：本地时间 vs 市场时间

我有个血的教训。之前做美股回测，服务器部署在新加坡。代码里用了 datetime.now() 记录订单时间。结果呢？回测出来的交易记录，买入时间比实际行情时间晚了12个小时。为什么？因为新加坡是 UTC+8，美股市场是 UTC-5（冬令时）。

你想想看，你的回测服务器可能在东京、在伦敦、在硅谷。每个地方的 datetime.now() 返回的都是当地时钟的时间。但金融市场有自己的时间规则——A股看北京时间，美股看美东时间，期货看交易所所在地时间。

核心原则：回测系统里永远不要用 datetime.now() 获取当前时间。要用 UTC 时间，或者明确指定市场时区。

陷阱2：时间精度问题

datetime.now() 默认精度是微秒级。听起来够用了对吧？但高频回测场景下，微秒级误差会导致订单排序错乱。我遇到过这样的情况：两个订单在同一微秒内到达，结果成交顺序反了，回测结果差了3个点。

为什么会这样？因为 datetime.now() 的精度取决于操作系统和硬件。Windows 上通常只有 15ms 左右的精度，Linux 上稍好一些。你想想，如果你的回测系统跑在 Windows 上，用 datetime.now() 记录 tick 级别数据，那基本就是瞎搞。

陷阱3：时间跳跃

这个坑比较隐蔽。系统时间可能会被 NTP 同步调整，或者被人为修改。如果回测过程中 datetime.now() 突然往回跳了1秒，你的时间序列就乱套了。我曾在生产环境遇到过，NTP 同步导致时间回跳，结果回测引擎直接崩溃。

二、时区处理的正确姿势

好了，陷阱说完了。那到底该怎么处理时区？我个人习惯用两种方案：pytz 和 Python 3.9 之后内置的 zoneinfo。

方案1：pytz（老项目首选）

pytz 是老牌时区库，兼容性好。但有个坑要注意——它的时区对象不能直接用在 datetime 的构造里。

import pytz
from datetime import datetime

# 错误写法（我见过很多人这么写）
# dt = datetime(2024, 1, 1, 9, 30, tzinfo=pytz.timezone('US/Eastern'))

# 正确写法
tz = pytz.timezone('US/Eastern')
dt = tz.localize(datetime(2024, 1, 1, 9, 30, 0))

print(dt)  # 2024-01-01 09:30:00-05:00

为什么不能直接传 tzinfo？因为 pytz 的时区对象包含历史时区变更信息，直接传会导致时区偏移量计算错误。嗯，这个坑我踩过，查了两天才找到原因。

方案2：zoneinfo（Python 3.9+ 推荐）

Python 3.9 之后，标准库自带了 zoneinfo。我个人更推荐这个方案，少一个依赖，而且 API 更干净。

from zoneinfo import ZoneInfo
from datetime import datetime

# 直接传 tzinfo 没问题
dt = datetime(2024, 1, 1, 9, 30, 0, tzinfo=ZoneInfo('US/Eastern'))
print(dt)  # 2024-01-01 09:30:00-05:00

# 转换到其他时区
utc_dt = dt.astimezone(ZoneInfo('UTC'))
print(utc_dt)  # 2024-01-01 14:30:00+00:00

你看，zoneinfo 的用法更直观。而且它用的是 IANA 时区数据库，和 pytz 是同一套数据源，结果是一致的。

三、回测系统中的时间戳最佳实践

说了这么多，到底该怎么设计回测系统的时间模块？我总结了一套方案，用了好几年，没出过问题。

黄金法则：内部统一用 UTC 时间戳，只在输入输出时做时区转换。

时间戳存储规范

场景 推荐格式 说明
数据库存储 Unix 时间戳（int64） 无时区歧义，排序快
内存计算 datetime(UTC) 方便加减运算
日志输出 ISO 8601 + 时区 人类可读，便于调试
API 交互 UTC 字符串 避免时区转换错误

实战代码：回测时钟模块

下面是我常用的时钟模块骨架。它解决了 datetime.now() 的所有问题。

from zoneinfo import ZoneInfo
from datetime import datetime, timezone
import time

class BacktestClock:
    """回测系统时钟，统一使用 UTC 时间"""
    
    def __init__(self, market_tz: str = 'Asia/Shanghai'):
        self.market_tz = ZoneInfo(market_tz)
        self._current_time = None
    
    def now_utc(self) -> datetime:
        """获取当前 UTC 时间（回测模式下返回模拟时间）"""
        if self._current_time:
            return self._current_time
        # 生产环境用 time.time() 避免 NTP 跳跃问题
        return datetime.fromtimestamp(time.time(), tz=timezone.utc)
    
    def now_market(self) -> datetime:
        """获取当前市场时间"""
        utc_now = self.now_utc()
        return utc_now.astimezone(self.market_tz)
    
    def set_time(self, dt: datetime):
        """设置模拟时间（用于回测）"""
        if dt.tzinfo is None:
            dt = dt.replace(tzinfo=self.market_tz)
        self._current_time = dt.astimezone(timezone.utc)
    
    def to_timestamp(self, dt: datetime) -> int:
        """datetime 转 Unix 时间戳（纳秒精度）"""
        if dt.tzinfo is None:
            dt = dt.replace(tzinfo=self.market_tz)
        utc_dt = dt.astimezone(timezone.utc)
        return int(utc_dt.timestamp() * 1_000_000_000)

这个模块有几个关键设计：

  • 统一 UTC 内核：所有内部计算都基于 UTC，避免时区污染
  • 模拟时间支持：回测时可以手动设置时间，不影响生产代码
  • 纳秒级时间戳：用 time.time() 替代 datetime.now()，精度更高
  • 时区隔离：市场时区只在输入输出层使用

四、避坑指南

最后分享几个我踩过的坑，希望能帮你省点时间。

我曾经... 在回测框架里直接用 datetime.now() 记录订单时间。结果回测和实盘对不上，查了三天才发现是时区问题。从那以后，我所有项目都强制要求用 UTC 时间戳。
注意：pytz 和 zoneinfo 的时区字符串可能不同。比如 'US/Eastern' 在 pytz 里能用，但 zoneinfo 里推荐用 'America/New_York'。建议统一用 IANA 标准名称。

还有一个细节：夏令时切换。每年3月和11月，美股市场会切换夏令时/冬令时。如果你的回测系统跨越了这些时间点，一定要用带时区的 datetime，否则时间偏移量会算错。

嗯，关于 datetime 的陷阱和时区处理，今天就聊到这儿。记住一句话：回测系统里，时间就是金钱。别让 datetime.now() 毁了你的策略。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →