navicat定时任务夏令时重复执行的根源是其默认用系统本地时区解析cron表达式且未做时间戳归一化，导致回拨时刻（如2:00 am edt→est）触发两次；确认方法为检查系统时区设置及任务计划中是否显示“local”；规避方案依次为：改用utc时区调度、禁用系统夏令时自动调整、避开2:00–3:00敏感窗口。
navicat 定时任务夏令时重复执行的根源
根本原因不是 navicat 本身 bug，而是它默认使用系统本地时区（local）解析 cron 表达式，且不区分标准时间与夏令时切换点。当系统进入夏令时（如北京时间不适用，但欧美多数地区适用），比如美国东部时间从 est → edt，时钟向前拨 1 小时——但 cron 调度器会把「2:00–3:00 这个被跳过的小时」误认为「2:00 出现了两次」（实际是回拨时才出现重复），而 navicat 的调度引擎在回拨时刻（如 2:00 am edt → 2:00 am est）**未做唯一性去重或时间戳归一化处理**，导致该小时内的任务被触发两次。
如何确认你的任务是否受夏令时影响
先查清楚你运行 Navicat 的机器时区设置和是否启用自动夏令时调整：
- Windows：控制面板 → 日期和时间 → 时区 → 勾选「自动调整夏令时」
- macOS：系统设置 → 通用 → 日期与时间 → 开启「自动设置日期与时间」和「自动检测时区」
- Linux（Navicat for Linux 较少，但若存在）：
timedatectl status看RTC in local TZ和Dynamic DNS hostname无关，重点看Time zone是否含daylight字样
再打开 Navicat 的「计划任务」列表，双击任一任务 → 「计划」选项卡 → 查看「执行时间」右侧是否显示「Local」；如果是，且你所在地区实行夏令时（如 US/Eastern、Europe/Berlin），就存在风险。
规避重复执行的三种实操方案
优先级从高到低排列，按实际环境选择：
- 改用 UTC 时区调度：在任务「计划」设置中，把「时区」下拉框从
Local改为UTC，然后手动把原计划时间换算成 UTC（例如原设每天 9:00 AM EST = UTC 14:00；EDT 则是 UTC 13:00；统一用 UTC 后无需切换）。这是最稳的方式，Navicat 对 UTC 的 cron 解析无夏令时歧义。 - 禁用系统夏令时自动调整（仅限可控服务器环境）：在 Windows 注册表修改
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\DisableAutoDaylightTimeSet设为1；Linux 下用sudo timedatectl set-local-rtc 0并固定时区如sudo timedatectl set-timezone Etc/UTC。注意：会影响其他应用，不推荐桌面环境使用。 - 避开 2:00–3:00 这个敏感窗口：如果必须用
Local且无法改时区，所有定时任务的分钟级触发点避开0 2 * * *这类整点设定，改用0 2,3 * * *或错开到15 1 * * *（即 1:15 AM），可绕过回拨重叠段。
为什么不能依赖 Navicat 自动修复
Navicat 的计划任务底层调用的是操作系统级定时机制（Windows Task Scheduler / macOS launchd / Linux cron），而它的 GUI 层只是配置封装。它不会主动注入 TZ=UTC 环境变量，也不对 cron 表达式做 DST-aware 解析。即使升级到最新版（v17.0+），只要时区选 Local，且系统开启夏令时，2:00 AM 回拨时刻仍会触发两次——这不是配置遗漏，是设计限制。
真正要根治，得让调度脱离本地时钟漂移；否则每次 DST 切换前后都得人工核对日志里有没有重复的 Task executed at ... 记录。
