n8n 截止日期总差一天：把时区、解析格式与日历计算分开

先问清“到期”指哪一刻 合同上写九月十二日到期，可能表示当地当天结束；接口里的带时区时间戳则表示一个确定时刻。若把两者都当成普通字符串比较，提醒可能提早或延后。建议先定义业务规则：按哪个地区的日历、在当天开始还是结束触发，以及空日期应怎样处理。 查看节点间实际传递的数据 n8n 官方文档说明，日期在节点之间会被转换为字符串。上一个节点显示的是日期，不代表下一个节点拿到的仍是可直接计算的日期对象。排查时保存原字符串和解析后的结果，不要只看最终漂亮的中文日期。 明确格式再解析 官方推荐使用 Luxon。ISO 格式可用 DateTime.fromISO，约定格式的字符串使用 fromFormat 并指定格式。对于类似 03/04 的内容，应让数据提供方明确月日顺序，不能靠猜测修复。业务样例中应加入无效日期、缺少年份和已经带偏移量的时刻，确认解析失败会进入可见分支。 核对真正生效的时区 Luxon 采用 n8n 的时区设置，来源可包括实例配置与工作流设置。官方同时提醒，原生 JavaScript Date 并不遵循某些 n8n 功能的工作流时区。于是同一流程混用两种计算方式时，即使公式看起来一致，也应分别检查结果。 本文建议在工作流备注中写出业务时区，并用当地午夜前后的一组样例核对日期。涉及有夏令时的地区时，再加入切换日前后的实际时间戳；不要把一天一律理解成业务上永远相同的小时数。 用一个跨午夜时刻定位“差一天” 自拟接口返回 2026-09-12T16:30:00Z。这是一个确定的 UTC 时刻，在 Asia/Shanghai 显示为 9 月 13 日 00:30。若业务按上海日期提醒，取 UTC 字符串的前十位会得到 9 月 12 日，正好差一天。先解析时刻、转换到业务时区，再取日历日期，不能靠给字符串手动加一天修复。 另一份输入只有 2026-09-12，没有时间和偏移，它可能只是业务约定的日期。应先确定“该日结束”还是“该日某个时刻”，然后在业务时区建立边界，不要把纯日期直接当作 UTC 午夜。可将“当天有效”表示为早于下一日零点的半开区间，避免依赖最后一毫秒的写法；是否采用这个规则由业务决定。 再用月末和夏令时地区的样例检查“加一个日历日”与“加 24 小时”是否符合原意。日历截止规则关心当地日期，持续时长关心经历了多久。两种计算都可能合理，关键是不要在同一规则中无意切换。 当前时刻与今日起点不同 $now 表示当前时间，$today 是当天零点。做“七天前这个时刻”的筛选与做“七天前那一天”的日报，需要的起点不同。先完成解析与日期运算，再转成人类可读字符串，可以减少显示格式参与计算造成的混淆。 保留便于复查的结果 建议输出原值、解析状态、采用的时区与最终截止时刻，展示字段另行生成。上线前用业务人员认可的日期样例复核，特别检查月末、年末和缺失值。

本篇涉及的工具1

n8n

通过 Luxon 解析与转换日期，并使用工作流时区处理日历计算。

适合场景

维护到期提醒、日报、排程数据与跨时区接口的 n8n 用户。

需要留意

纯日期与带偏移时刻应分别处理；截止含义由业务规则确定。

了解项目 访问官网