别再被时间格式搞晕了：UTC 转北京时间其实很简单
笔者在 N8N大学 接到过无数个咨询，其中高频出现的一个问题就是：“我的数据里是 UTC 时间，怎么转成中国标准时间（CST）？” 这种问题通常出现在对接海外 API、处理数据库日志或者跨国协同办公的场景中。
如果你还在用 Excel 或者写 Python 脚本来处理时间转换，那真的太原始了。在 n8n 的世界里，这本该是一个 Date & Time 节点就能解决的丝滑操作。但因为时区、格式化字符串的坑，很多人在这里翻了车。今天，笔者就带你彻底搞定 n8n 中的时间处理，从 UTC 到北京时间，一步到位。
核心痛点：为什么时间转换总是报错？
在 n8n 中，时间处理的核心逻辑其实非常简单，但容易混淆的点在于：输入是什么格式，你要输出什么格式，以及中间如何转译时区。
很多新手遇到的典型场景是：上游节点（比如 HTTP Request）拉回来的 JSON 数据里，时间戳是 2023-10-27T08:00:00Z（这就是 UTC 标准格式，Z 代表 UTC）。而你的业务系统或者飞书/钉钉机器人，需要的是 2023-10-27 16:00:00 这种格式。
这里有两个核心变量：
- 时区（Timezone）： n8n 默认运行在服务器的时区（通常是 UTC），如果你不显式指定，它就会按 UTC 算，导致你得到的时间总是比预期慢 8 小时。
- 格式（Format）： 年月日时分秒的排列组合，差一个符号都会导致后续节点解析失败。
实战操作：三步搞定 UTC 转北京时间
下面笔者带大家走一遍标准流程。假设我们有一个输入数据，字段名为 utc_time，值为 2023-10-27T08:00:00Z。我们的目标是生成一个北京时间的可读字符串。
第一步：准备数据 (Set Node)
为了演示，我们先用一个 Set 节点模拟数据源。在 Fields 中添加一个字段：
- Name:
utc_time - Value:
2023-10-27T08:00:00Z
这一步是为了确保你明白我们要处理的数据长什么样。
第二步：时区转换 (Date & Time Node)
这是最关键的一步。拖拽一个 Date & Time 节点进来，我们需要配置两个地方：
- Mode (模式)： 选择
Convert Timezone（转换时区）。 - Source Time String (源时间字符串)： 填入
{{ $json.utc_time }}。这里 n8n 会自动识别 UTC 格式。 - Source Timezone (源时区)： 默认即可，或者显式选
UTC。因为我们的数据带Z。 - Target Timezone (目标时区)： 这是重点！ 请搜索并选择
Asia/Shanghai。不要选错成Asia/Chongqing或其他，虽然它们时间一样，但规范选Shanghai。 - Output Format (输出格式)： 这里你可以自定义，比如
yyyy-MM-dd HH:mm:ss。如果你想保留原始 ISO 格式但只是变了时区，可以留空或选默认。
做完这一步，你得到的数据已经是北京时间了，只是可能格式还不是你想要的。
第三步：格式化输出 (Date & Time Node)
如果你对上一步输出的格式不满意（比如想加个星期几，或者改成中文格式），可以再串联一个 Date & Time 节点，或者直接在上一个节点里配置 Output Format。
通常推荐在第二步直接配置好 Output Format，例如填入：
yyyy-MM-dd HH:mm:ss
这样输出就是完美的 2023-10-27 16:00:00。
如果你需要更花哨的格式，比如 2023年10月27日 16:00:00 星期五，你需要用到以下占位符：
yyyy= 年MM= 月dd= 日HH= 24小时制小时mm= 分ss= 秒EEEE= 星期几（中文需要配合 i18n 设置，通常在前端处理，后端建议输出标准格式）
硬核避坑指南：笔者的血泪经验
在 N8N大学 的社区里，关于时间节点的报错通常集中在以下两点，请务必注意：
1. “时间戳”与“时间字符串”的混淆
很多 API 返回的是 Unix 时间戳（比如 1698384000000，13位毫秒级）。如果你直接把这串数字丢进 Date & Time 节点的 Source Time String，n8n 会报错或者解析成 1970 年。
解决方案： 如果是时间戳，Mode 要选 Format a Timestamp，而不是 Convert Timezone。或者，你先用 JavaScript 节点把时间戳转成 ISO 字符串，再给 Date & Time 处理。
2. 时区字符串的拼写错误
n8n 的时区选择器是下拉菜单，但如果你是手动输入字符串，必须严格遵守 IANA 格式。比如输入 Beijing 或 China 是无效的，必须是 Asia/Shanghai。
笔者建议： 永远使用下拉菜单选择，不要手写，除非你对 IANA 时区数据库非常熟悉。
3. 夏令时（DST）的陷阱
虽然中国不实行夏令时，但如果你处理的是美国或欧洲的时间，务必注意 America/New_York 在夏天和冬天的偏移量是不同的。n8n 的 Date & Time 节点会自动处理这个问题，前提是你的 Source Timezone 填对了。如果你填的是固定的 UTC-5，在夏令时期间就会出错。所以，永远优先选地区名（如 America/New_York），而不是固定偏移量。
FAQ 问答
Q1: 我的 n8n 面板语言是中文，为什么 Date & Time 节点生成的日期还是英文？
A: n8n 节点的输出格式主要依赖于你填写的 Format String（格式字符串）和底层的 JavaScript 库。如果你想要中文的“2023年10月27日”，你需要在格式字符串里手动填入“年”、“月”、“日”这些汉字字符。n8n 本身不会自动根据界面语言去翻译日期输出，这需要你在配置时自定义。
Q2: 为什么我转换后的时间还是比实际少 8 小时？
A: 这通常是因为你只改了格式，没改时区。检查一下你的 Date & Time 节点 Mode 是否选对了。如果你是从 UTC 转上海，Mode 必须是 Convert Timezone，并且 Target Timezone 显式选了 Asia/Shanghai。如果 Mode 是 Format a Date String，它只负责换皮，不负责挪时区。
Q3: 这个节点免费版能用吗？
A: 完全可以。Date & Time 是 n8n 的核心内置节点，无论你是 Cloud 版、免费的 Self-hosted 版，还是付费的企业版，这个节点都是开箱即用的，没有任何功能限制。
总结与资源
搞定时间格式，本质上就是搞懂 时区（Where） 和 格式（How）。在 n8n 中，Date & Time 节点是一个非常强大的工具，只要记住核心原则：先定区，再格式化。
如果你在处理时间时还需要进行复杂的逻辑判断（比如判断是否在工作时间），可以结合 Switch 节点使用。更多 n8n 的进阶玩法，欢迎持续关注 N8N大学 (n8ndx.com)，这里有你最需要的实战干货。
