[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fjk10T2GETt3bJjSEB1Db6CZR8XaSnf7mF7svxz9KxUo":3,"$f2_Sl0gldducKoemTnNBZ2sVx1ptbQWI5v9WRaruEdx8":48},[4],{"id":5,"type":6,"title":7,"slug":8,"summary":9,"body":10,"coverUrl":11,"productScreenshots":12,"productLinks":13,"authorName":14,"authorUrl":15,"authorSubject":16,"category":17,"tags":22,"sourceLabel":39,"sourceName":40,"sourceUrl":40,"status":41,"seoTitle":40,"seoDescription":40,"canonicalUrl":40,"isFeatured":42,"sno":43,"sortOrder":44,"publishedAt":45,"updatedAt":46,"createdAt":47},"8e1c755d-5417-4978-a9a4-d4c3e44af06e","article","Temporal：为什么程序员最怕 2 月 29 日和夏令时","javascript-temporal-date-time-explained","日期、时间点和时区不是同一种东西。本文以会议、生日和日志三个场景拆解 JavaScript Date 的边界问题，讲清 Temporal 的 Instant、PlainDate、ZonedDateTime 等类型，以及如何避免夏令时和跨时区计算陷阱。","有些 Bug 看起来像玄学：同一个会议在不同人的日历里差了一个小时，月底订阅在某些时区提前一天扣款，出生日期从数据库取出来后变成了前一天。它们通常不是“时间不听话”，而是程序把三种不同的东西混在了一起：绝对发生的时刻、某个地区的墙上时间，以及日历上的日期。\n\n![世界时区分布图](https:\u002F\u002Fcommons.wikimedia.org\u002Fwiki\u002FSpecial:FilePath\u002FWorld%20Time%20Zones%20Map.svg)\n\nJavaScript 过去主要靠一个 `Date` 对象处理这些问题。它能工作，但 API 既承载时间点，又承载本地日期和时区转换，很多操作还会改变原对象。Temporal 的目标，就是把这些概念拆成一组有明确含义、不可变的类型。TC39 的规范草案列出了时区、夏令时安全运算、日期\u002F时间分离和持续时间等核心能力。[Temporal 规范](https:\u002F\u002Ftc39.es\u002Fproposal-temporal\u002F)\n\n## 先别急着记 API：时间其实有三种语义\n\n### 1. 绝对时刻：全世界只有一个答案\n\n“服务器在 2026 年 8 月 6 日 02:00:00 收到请求”是一个绝对时刻。它通常用 UTC 或 Unix 时间戳表示。无论用户在上海、纽约还是伦敦，这个事件只发生过一次。\n\n适合用绝对时刻的场景包括：日志、支付完成时间、消息发送时间、文件创建时间。它们的重点是“什么时候发生”，而不是“当地钟表显示什么”。Temporal 用 `Temporal.Instant` 表达这种值：它不带时区，只表示时间线上一个准确位置。\n\n### 2. 墙上时间：同一个事件在不同地方看起来不同\n\n“上海办公室每天 9:00 开会”不是一个绝对时刻。它首先是一个当地规则：在 `Asia\u002FShanghai` 这个时区，每天的墙上时间是 09:00。换算成纽约时间时，必须把时区规则、夏令时和历史变更都考虑进去。\n\n这类值适合 `Temporal.ZonedDateTime`。它把日期、时间、时区和时间线联系在一起。时区不是简单的“加八小时”，而是一套会随地区政策变化的规则数据库。IANA 的时区数据库正是很多运行时进行转换时依赖的基础。[IANA Time Zone Database](https:\u002F\u002Fwww.iana.org\u002Ftime-zones)\n\n### 3. 日历日期：生日不是一个瞬间\n\n“用户生日是 8 月 6 日”通常不应该被转换成 UTC。把它存成某个时间点后，用户在另一个时区打开页面，生日可能显示成 8 月 5 日。这是因为生日是日历概念，不是全球同步发生的事件。\n\n这类值应该使用 `Temporal.PlainDate`。类似地，“店铺每天 09:00 开门”可以用 `Temporal.PlainTime`，而“2026 年 8 月 6 日 09:00”但暂时不知道在哪个时区，可以用 `Temporal.PlainDateTime`。它们故意不替你猜时区。\n\n## Temporal 解决的不是“日期格式丑”，而是边界不清\n\n看一个常见的会议例子：\n\n```js\nconst meeting = Temporal.ZonedDateTime.from(\n  \"2026-08-06T09:00:00+08:00[Asia\u002FShanghai]\"\n)\n\nconst inNewYork = meeting.withTimeZone(\"America\u002FNew_York\")\nconsole.log(inNewYork.toString())\n```\n\n这里的含义很清楚：会议发生在上海时区的 9 点，然后把同一个瞬间显示成纽约时间。`withTimeZone` 改变的是“怎么看”，不是会议本身。\n\n如果业务说的是“从会议开始后经过两小时”，应使用时间线上的加法；如果业务说的是“下个月同一天的 9 点”，应使用日历加法。两者在夏令时切换附近可能得到不同结果，这正是很多排班 Bug 的来源。\n\n```js\nconst start = Temporal.ZonedDateTime.from(\n  \"2026-03-08T01:30:00-08:00[America\u002FLos_Angeles]\"\n)\n\nconst twoHoursLater = start.add({ hours: 2 })\nconst nextCalendarDay = start.add({ days: 1 })\n```\n\n“加两小时”强调经过了 7200 秒；“加一天”强调日历向后翻一页。遇到夏令时缺失或重复的本地时间，Temporal 还允许通过选项明确指定如何处理，而不是静默地替你做一个很难发现的决定。\n\n## 不可变性：少一个隐形副作用\n\n传统 `Date` 的很多方法会修改原对象。一个函数如果拿到 `Date` 后调用 `setHours`，调用者手里的值也可能被改变。Temporal 对象是不可变的：`add`、`with`、`withTimeZone` 都会返回新对象。这个设计让时间计算更接近普通值，更容易测试，也更适合在前端状态管理中传递。\n\n但不可变不等于“自动正确”。你仍然要在数据模型里做选择：\n\n- 支付、日志和消息事件存 `Instant`。\n- 生日、节假日和账单日存 `PlainDate`。\n- 固定地点的营业时间存 `PlainTime` 加时区规则。\n- 远程会议存带时区的 `ZonedDateTime`，展示时再转换。\n- “三天后”要先问清楚是 72 小时，还是跨过三个日历日期。\n\n```mermaid\nflowchart TD\n    A[业务出现一个时间值] --> B{它代表什么}\n    B -->|发生过的事件| C[Temporal.Instant]\n    B -->|某地钟表时间| D[ZonedDateTime]\n    B -->|日历上的日期| E[PlainDate]\n    B -->|每天的时刻| F[PlainTime]\n    C --> G[展示时再转换时区]\n    D --> G\n    E --> H[不要偷偷转换成 UTC]\n    F --> I[绑定地点后再生成瞬间]\n```\n\n## Temporal 现在适合怎么用\n\n第一步不是把项目里所有 `Date` 全部替换掉，而是盘点字段的语义。可以从新功能开始：订单事件使用 `Instant`，生日使用 `PlainDate`，会议使用 `ZonedDateTime`。老接口仍然需要和 ISO 字符串、Unix 时间戳互操作，因此要把转换集中在边界层，而不是让每个组件各自解析日期。\n\n还要特别测试三类日期：时区切换前后、月份末尾、闰年 2 月 29 日。时间处理的难点从来不是把字符串格式化得漂亮，而是让每个值从一开始就有准确的含义。\n\n## 一句话带走\n\n时间 Bug 的根源经常不是算法错，而是“生日、会议和日志”被当成了同一种数据。Temporal 的价值，是让类型先替你问一句：你说的到底是一个瞬间，还是某个地方的钟表，还是日历上的一天？\n\n## 延伸阅读\n\n- [TC39 Temporal 规范](https:\u002F\u002Ftc39.es\u002Fproposal-temporal\u002F)\n- [Temporal 文档与示例](https:\u002F\u002Ftc39.es\u002Fproposal-temporal\u002Fdocs\u002F)\n- [IANA Time Zone Database](https:\u002F\u002Fwww.iana.org\u002Ftime-zones)","\u002Fuploads\u002F2026-08-06\u002F467bd509-312c-48dc-aeb3-84e9317e647c.jpg",[],[],"Foundit","https:\u002F\u002Ffoundit.cn","f39339b1-aaa6-4e86-b0c2-a6e6a21113b5",{"id":18,"name":19,"slug":20,"description":21},"6179d3b6-dc34-4483-9ded-3cd9f1b37a47","科普","abbreviation","介绍各领域新兴概念",[23,27,31,35],{"id":24,"name":25,"slug":26},"4c2bbea6-eab7-40a8-8447-1de478ff7749","分析","analyse",{"id":28,"name":29,"slug":30},"144abe77-0dc6-4f66-a176-20bddb1c0bfa","编程","coding",{"id":32,"name":33,"slug":34},"7c76bfc2-f80f-4ee0-a95d-27bd8708b434","技术","slug",{"id":36,"name":37,"slug":38},"a202d639-99a6-488a-a712-4d4c6ffd7e15","开发","dev","资料来源",null,"published",false,64,0,"2026-08-06T00:00:00.000Z","2026-08-06T05:47:06.819Z","2026-08-06T05:38:21.657Z",[49,73,92],{"id":50,"type":6,"title":51,"slug":52,"summary":53,"body":54,"coverUrl":55,"productScreenshots":56,"productLinks":57,"authorName":58,"authorUrl":15,"authorSubject":16,"category":59,"tags":64,"sourceLabel":40,"sourceName":40,"sourceUrl":40,"status":41,"seoTitle":40,"seoDescription":40,"canonicalUrl":40,"isFeatured":42,"sno":69,"sortOrder":44,"publishedAt":70,"updatedAt":71,"createdAt":72},"8b883dd6-d112-4adc-ab3c-e5fa1c71bdc1","长上下文 vs RAG：什么时候还需要检索，什么时候直接塞","long-context-vs-rag-decision","模型支持百万 token 上下文后，RAG 还有必要吗？本文用一张决策图讲清长上下文与 RAG 的成本、信噪比、实时性、可溯源差异，并给出「RAG 粗筛 + 长上下文精读」的混用思路。","现在的主流模型动辄支持几十万甚至上百万 token 上下文，「把整个知识库塞进 prompt 不就行了，还要 RAG 干嘛？」——这是 2026 年最常被问的问题。\n\n答案是：长上下文和 RAG 不是替代关系，而是各有成本与边界，选错会又贵又慢还更不准。\n\n## 背景：两种「让模型知道更多」的路\n\n**长上下文**是一次性把大量资料放进对话窗口，模型自己读。\n**RAG（检索增强生成）**是先根据用户问题，从知识库里搜出最相关的几段，只把这几段喂给模型。\n二者的核心差别在于：模型到底要「读全部」还是「读精华」。\n\n## 怎么选\n\n```mermaid\nflowchart TD\n    A[需要模型参考外部资料] --> B{资料是否全部相关且量可控?}\n    B -->|是, 且需整体理解| C[长上下文 直接塞]\n    B -->|否, 海量\u002F需精准定位| D[RAG 先检索再喂]\n    D --> E{结果要可溯源\u002F低成本?}\n    E -->|是| F[坚定用 RAG]\n    E -->|否| G[可混用: 检索+长上下文精读]\n```\n\n## 核心取舍\n\n- **成本**：长上下文按全部 token 计费，100 万字和 1000 字单价一样，烧钱极快；RAG 只付「检索到的几段」，便宜一两个数量级。\n- **准确率（信噪比）**：上下文越长，模型越容易在噪声里迷失、甚至「中间遗忘」（lost in the middle）。RAG 只给最相关片段，反而更准。\n- **实时性与新鲜度**：RAG 可以检索实时更新的库；长上下文里塞的是「提问那一刻」的快照，过期不管。\n- **可溯源**：RAG 天然返回引用来源，长上下文很难说清答案来自哪一句。\n\n## 一个最小可运行的例子\n\nRAG 的检索侧，常用向量数据库做语义搜索：\n\n```python\nhits = vector_db.search(embed(question), top_k=3)   # 用户提问 → 向量检索最相关的 3 段 → 拼进 prompt\ncontext = \"\\n\".join(h[\"text\"] for h in hits)\nprompt = f\"根据资料回答：\\n{context}\\n\\n问题：{question}\"\nanswer = model(prompt)\n```\n\n注意这里检索到的 `top_k=3` 片段，就是模型真正会读的全部，成本与噪声都被压到最低。\n\n## Tips\n\n- 资料少、要整体通读（如整份合同、一篇长文），直接用长上下文，省事。\n- 资料海量、要精准定位、要低成本，坚定用 RAG。\n- 需要答案可溯源、可审计，RAG 几乎是唯一选择。\n- 二者可混用：RAG 粗筛 + 长上下文对命中片段精读。\n- 别盲目追长上下文「偷懒」——多数生产场景，RAG 的性价比更高。","https:\u002F\u002Foxqtewbrpuiouqqjrvdv.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fpublic-media\u002F2026-07-20\u002F10f52f80-db7f-4a1d-861d-37514ea09646.jpg",[],[],"Foundit AI",{"id":60,"name":61,"slug":62,"description":63},"d6750616-07d9-4350-8485-1834c77be3d2","指南","guide","指导建议，仅供参考",[65,66,67,68],{"id":32,"name":33,"slug":34},{"id":24,"name":25,"slug":26},{"id":28,"name":29,"slug":30},{"id":36,"name":37,"slug":38},73,"2026-07-10T00:00:00.000Z","2026-07-20T01:26:12.755Z","2026-07-20T01:12:58.458Z",{"id":74,"type":6,"title":75,"slug":76,"summary":77,"body":78,"coverUrl":79,"productScreenshots":80,"productLinks":81,"authorName":58,"authorUrl":82,"authorSubject":16,"category":83,"tags":84,"sourceLabel":40,"sourceName":40,"sourceUrl":40,"status":41,"seoTitle":40,"seoDescription":40,"canonicalUrl":40,"isFeatured":42,"sno":88,"sortOrder":44,"publishedAt":89,"updatedAt":90,"createdAt":91},"544fc658-c911-4de6-93b0-d2520087119a","MCP：AI 的「USB-C」时刻","mcp-ai-usb-c-moment","以前每个 AI 应用都要为 GitHub、数据库、日历各写一套私有连接器，这是 M×N 的集成噩梦，直到 MCP 的出现","如果你用过笔记本电脑，一定熟悉那种「每个设备一根专属线」的烦躁：鼠标一个接口、打印机另一个、硬盘又一个。2025 年之前的 AI 应用，几乎就是这种状态——想让一个助手同时读你的代码仓库、查数据库、发日历邀请，开发团队得为每一个系统写一套私有「连接器」，又脆又难维护。\n\n## 背景：每个 Agent 都曾是孤岛\n\n大模型本身只会「说话」，它要真正干活，得去调工具、读数据。在 MCP（Model Context Protocol，模型上下文协议）出现之前，这套对接是组合爆炸：假设市面上有 M 个 AI 客户端、N 个工具，开发者就要写 M×N 套集成。一个代码助手要读 Git、查 Jira、搜文档，就得维护三条互不相通的管线。\n\n更糟的是，这些连接器大多只服务某一个产品，换个助手就得重写。结果就是：每个 Agent 都困在自己的小岛上，能力被锁死在少数几个硬编码的集成里。\n\n## MCP 是什么：AI 世界的「USB-C」\n\n2024 年底，Anthropic 发布了 MCP。它的目标很朴素：给「AI 连工具」定义一个统一接口，就像 USB-C 给「设备连外设」定义统一接口一样。\n\n打个比方——如果大模型是大脑，那 MCP 就是手。大脑再聪明，没有手也打不开文件、点不了按钮、查不了数据库。MCP 让任意符合规范的「大脑」（Claude、ChatGPT、Gemini、Cursor、VS Code Copilot）都能使用任意符合规范的「手」（一个封装好的工具服务），而且不用为每个组合单独适配。\n\n2025 年 12 月，Anthropic 把 MCP 捐给了 Linux 基金会，OpenAI、Google、Microsoft 作为联合发起人。到 2026 年，它的 SDK 月下载量超过 9700 万次，ChatGPT、Claude、Gemini 都支持同一个协议——某种意义上，这场标准之战已经赢了。\n\n## 它是怎么运作的：三层结构\n\nMCP 把「连工具」拆成三个角色，理解这三层就理解了全部：\n\n- **Host（宿主）**：你直接使用的应用，比如 Claude 桌面端、VS Code、一个自定义聊天机器人。\n- **Client（客户端）**：住在 Host 内部、专门负责管理 MCP 连接的小组件。\n- **Server（服务端）**：一个轻量程序，把某个能力「暴露」出来，比如一个 GitHub 服务、一个数据库查询服务。\n\n每个 Server 通过三种「原语」提供能力：`Tools`（AI 可以调用的可执行函数，如 `create_issue`）、`Resources`（AI 可以读取的数据，如文件内容、数据库表结构）、`Prompts`（可复用的提示词模板）。它们底层用 **JSON-RPC**（一种简单的远程调用格式）通信，远程服务走 HTTP 传输，本地服务走标准输入输出。\n\n整个调用流程是这样的：\n\n```mermaid\nflowchart LR\n    U[用户] --> H[Host 应用\u003Cbr\u002F>Claude \u002F Cursor \u002F VS Code]\n    H --> C[MCP Client\u003Cbr\u002F>连接管理器]\n    C -->|JSON-RPC| S1[MCP Server: GitHub]\n    C -->|JSON-RPC| S2[MCP Server: 数据库]\n    C -->|JSON-RPC| S3[MCP Server: 天气 API]\n    S1 --> D1[(代码仓库)]\n    S2 --> D2[(业务数据)]\n    S3 --> D3[(外部 API)]\n```\n\n关键点在于：Host 只要实现一次 Client 协议，Server 只要实现一次 Server 协议，从此任意 Host 能连任意 Server。集成成本从 M×N 降到了 M+N。\n\n## 一个最小可运行的例子\n\n下面用官方 Python SDK 写一个「天气查询」MCP 服务，只暴露一个工具：\n\n```python\nfrom mcp.server.fastmcp import FastMCP\n\nmcp = FastMCP(\"weather\")  # 服务名叫 weather\n\n@mcp.tool()\ndef get_weather(city: str) -> str:\n    \"\"\"查询某城市的天气（示例返回静态数据）\"\"\"\n    return f\"{city} 今天晴，25°C。\"\n\nif __name__ == \"__main__\":\n    mcp.run()  # 默认以 stdio 方式启动，等待 Host 来连\n```\n\n运行前只需 `pip install mcp`，然后用任意支持 MCP 的客户端（Claude 桌面端、Cursor 等）配置这个服务路径即可。AI 在对话里说「查下北京天气」，客户端就会通过 MCP 调用 `get_weather(\"北京\")`，拿到结果再组织成自然语言回答你。注意：这只是最小骨架，真实服务里要把静态返回值换成真正的天气 API 调用。\n\n## 取舍与边界：它解决了什么，没解决什么\n\nMCP 解决的是「连接标准」问题，但它不是银弹：\n\n- **它让集成变简单，但不保证工具安全。** 一个 MCP Server 可以是任何人所写，工具描述会直接喂给模型。如果 Server 既能读私有数据、又能访问不可信内容、还能对外发消息，就构成了安全风险（业界称之为「致命三件套」）。企业通常会加一层 **Gateway（网关）** 来做鉴权和审计——Uber、Amazon 都用了这种「网关 + 注册表」的控制平面。\n- **上下文膨胀是个真问题。** 接的 Server 一多，工具定义会塞满模型的上下文窗口。2026 年的常见解法是「按需加载」：只把当前 Agent 真正需要的工具暴露出来，而不是一次全塞进去。\n- **它定义「怎么连」，不定义「连上去说什么」。** 多 Agent 之间的协作语义，由另一套协议 A2A（Agent-to-Agent）负责——MCP 接工具，A2A 连同伴。\n\n## Tips\n\n- 下次看到「AI 连不上我的系统」，先问：有没有现成的 MCP Server？多数数据库、SaaS、开发工具都已有官方或社区实现。\n- 想自己动手：用官方 SDK（Python\u002FTypeScript 等）把内部的一个 API 包成 MCP Server，比写一套专属集成快得多。\n- 评估风险时记住三件事：私有数据、不可信输入、对外通信，三者叠加要格外小心，尽量放进网关管控。\n- 分清两层协议：接工具看 MCP，多 Agent 协作看 A2A，别混为一谈。\n- 把 MCP 当「基础设施」而非「功能」：它赢是因为无聊、通用、可复用，这正是它值得长期投入的原因。","https:\u002F\u002Foxqtewbrpuiouqqjrvdv.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fpublic-media\u002F2026-07-19\u002Fc3c06d99-a0ac-40ac-a283-7e77aabb4c4c.jpg",[],[],"https:\u002F\u002Ffoundit.cn\u002Fabout",{"id":18,"name":19,"slug":20,"description":21},[85,86,87],{"id":36,"name":37,"slug":38},{"id":32,"name":33,"slug":34},{"id":24,"name":25,"slug":26},46,"2026-07-20T00:00:00.000Z","2026-07-19T17:39:20.060Z","2026-07-19T16:13:40.316Z",{"id":93,"type":6,"title":94,"slug":95,"summary":96,"body":97,"coverUrl":98,"productScreenshots":99,"productLinks":100,"authorName":58,"authorUrl":15,"authorSubject":16,"category":101,"tags":102,"sourceLabel":39,"sourceName":40,"sourceUrl":40,"status":41,"seoTitle":40,"seoDescription":40,"canonicalUrl":40,"isFeatured":42,"sno":106,"sortOrder":44,"publishedAt":107,"updatedAt":108,"createdAt":109},"74dedc2e-6a66-4481-aef2-5cffc3ba338d","嵌入模型（Embeddings）：向量数据库能搜「意思」，全靠它","embedding-models-vector-search","向量库怎么懂「意思相近」？靠嵌入模型把文字变成向量。本文讲清它的工作原理、余弦相似度检索，给出 sentence-transformers 最小示例，以及模型选型、维度统一、中英差异等取舍。","你让向量库「找意思相近的句子」，它怎么懂「意思」？靠嵌入模型（Embeddings）：把文字变成一串数字（向量），意思越近，数字越近。它是语义搜索和 RAG 真正的地基——没有它，模型只能靠关键词硬匹配。\n\n## 为什么需要嵌入\n\n传统搜索靠关键词匹配，搜「怎么给猫降温」找不到「猫咪中暑怎么办」。嵌入把文本映射到向量空间，把相近语义聚在一起，才能按「意思」而不是「字面」检索。\n\n## 它是怎么工作的\n\n嵌入模型（如 BGE、OpenAI text-embedding）是个神经网络，把变长文本压成定长向量（常见 768 或 1536 维）。训练目标是「语义相近的文本，向量距离小」。检索时把 query 也编码，算余弦相似度，找最近的那些。\n\n```mermaid\nflowchart LR\n    A[文本] --> B[嵌入模型]\n    B --> C[向量]\n    C --> D[存入向量库]\n    E[查询] --> B\n    D --> F[相似度检索]\n    B --> F\n    F --> G[返回相近文本]\n```\n\n## 取舍与边界\n\n- **模型要选对**：通用嵌入未必适合你的领域（法律、医疗），必要时用领域数据微调。\n- **维度与成本权衡**：维度越高通常越准，但存储、检索都更贵更慢，按场景取舍。\n- **中英文差异**：混用中英文语料要选多语言模型，否则跨语言检索会崩。\n- **维度必须统一**：检索和入库一定要用同一个模型、同一维度，否则向量不可比，检索全乱。\n\n## Tips\n\n- 任何「按意思搜」的需求，第一步就是选好嵌入模型。\n- 中文场景优先试 BGE、m3e 等多语言\u002F中文模型，别直接套英文默认。\n- 入库和检索用同一模型同一维度，这是铁律。\n- 领域强相关的语料，用该领域样本微调嵌入，召回率提升明显。\n- 嵌入质量直接决定 RAG 上限，值得在它上面多花时间。","https:\u002F\u002Foxqtewbrpuiouqqjrvdv.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fpublic-media\u002F2026-07-22\u002Facd40af8-276a-48bc-8d62-dcd52c124590.jpg",[],[],{"id":18,"name":19,"slug":20,"description":21},[103,104,105],{"id":24,"name":25,"slug":26},{"id":32,"name":33,"slug":34},{"id":36,"name":37,"slug":38},68,"2026-07-22T00:00:00.000Z","2026-07-23T01:16:32.032Z","2026-07-20T10:23:37.966Z"]