时区目录与 DST（夏令时）展示优化

版本：v1.6 | 创建日期：2026-08-04 | 最近更新：2026-08-05
需求来源：需求池 2026-07-10-25569、关联需求反馈（当前共 3 条）、系统现状截图、竞品截图、本地代码与国际标准
优先级：P1（建议，待评审确认）
文档状态：待确认

需求变更记录

变更日期	变更人	变更内容
2026-08-04	孙浩 / AI 协作	补充关联需求反馈分析、116 项目录缺口、Slack 规则和搜索体验；夏令时标签改为仅当地当前处于夏令时期间显示。
2026-08-05	孙浩 / AI 协作	补充泰国/越南完整性核验、主动补齐目录分级和 7 个特殊 value 逐条风险；明确 Excel 只承载本系统目录审计，竞品仅在 PRD 中呈现。

依赖需求 Story 列表

当前无独立依赖 Story。服务端、Web 和移动端使用同一规则口径，是本需求自身的交付范围，不拆成外部依赖。

ID	需求描述	涉及端与开发人员	是否有依赖项	备注
无	无	无	否	无

一、需求概述

1.1 客户反馈

客户反馈结论： 需求池当前关联 3 条需求反馈，分别暴露了三个不同问题：城市名称没有按当前语言展示和参与搜索、合法 IANA ID 缺项、标准偏移标签被用户误解为当前实际偏移。三条反馈均已取得编号、客户场景或截图证据，不能再写成“无关联反馈”或只归因为“缺时区”。

反馈编号	反馈客户	反馈原文/已核实事实	AI 分析	证据状态
`fb_2026-07-03_064754`	苏州贝瓦科技有限公司（重要）	用户想选择“悉尼”时区，但按中文“悉尼”搜索无法定位目标项，因而认为系统没有悉尼时区；当前列表中实际已存在`Australia/Sydney`。该反馈含 2 张 PNG 附件。	核心是本地化展示与搜索问题，不是缺少 Sydney。现有选项主要暴露英文 value/英文城市，中文用户不能用当前语言搜索。Sydney 与 Brisbane 的 DST 规则确实不同，因此搜索命中后仍必须保存各自 IANA ID，不能互相替代。	编号、客户、场景和附件数量已核实；完整逐字原文与附件需 CRM 重新取回后补入。
`fb_2026-07-23_065215`	WinGD Ltd.	客户角色：瑞士客户 CRM 系统使用人员。业务场景：设置个人时区为本地时区`[Europe/Zurich]`。操作及问题：个人设置/语言时区设置点击同步时无法同步。纷享版本 8.8.5。	`Europe/Zurich` 是 IANA `zone1970.tab` 中瑞士、德国 Buesingen 和列支敦士登的代表规则 ID；当前目录缺失 Zurich，导致设备返回该标准 ID 时无法在下拉列表中精确匹配。必须新增为可选择项，不能只依赖 Vaduz/Busingen 等规则等价值。
`fb_2025-04-16_054096`	深圳市斯科尔科技股份有限公司	APP 中芝加哥显示`(GMT-06:00)`；客户指出当地已进入夏令时，当前实际偏移应为 `UTC-05:00`，静态标签容易产生错误引导。版本 8.8.5，关联 Bug `fb_106730`。	现有标签展示的是芝加哥标准偏移，但界面没有说明“标准偏移”，用户自然会把它当成当前偏移。该反馈支持统一标准偏移口径，同时要求增加明确说明和“当前为夏令时”状态；不能把列表数字直接改成季节动态值，否则会与已确认的 Outlook 式稳定目录方案冲突。

整体需求由三类客户问题组成：

搜索本地化问题： 已有 Sydney，但用户用“悉尼”搜不到；城市中文名、英文名、国家/地区和 IANA ID 必须共同参与搜索。
目录完整性问题： 设备或用户提供 Europe/Zurich 等合法标准 ID 时，系统必须能够搜索、匹配和保存，不能因为前台目录缺项而同步失败。
展示口径问题： Chicago 的 GMT-06:00 是标准偏移，不代表当前夏令时偏移；列表必须解释清楚，并将实际换算与静态标签彻底分离。

1.2 系统现状

当前系统已经支持用户选择 IANA 时区，并在日期时间字段等场景中按用户/租户时区格式化时间。本期不是重新建设多时区换算，而是解决时区列表的展示口径不统一，以及 DST 标签与真实状态不一致的问题。

最容易理解的例子是纽约和悉尼：

城市	纷享销客当前列表	同期实际状态	暴露的问题
纽约	`GMT-05:00 北美东部标准时间(America/New_York)`	Google 截图显示`GMT-04:00`，说明当时纽约处于夏令时	纷享销客显示的是标准偏移，未显示当前真实偏移
悉尼	`GMT+11:00 澳大利亚东部夏令时间(Australia/Sydney)`	Google 截图显示`GMT+10:00`，说明当时悉尼处于标准时间	纷享销客显示的是夏令时偏移，未显示当前真实偏移

这两条放在一起，问题就很明确：当前列表没有统一遵循“标准偏移”或“当前偏移”中的任何一种规则，而是纽约使用标准偏移、悉尼使用夏令时偏移。 用户无法从列表判断 GMT 数字代表固定标准时间，还是当前实际时间。

同时，两条时区下方都显示“已支持夏令时”。根据本次确认的产品口径，该标签用于提示当地当前正处于夏令时期间：当前处于夏令时则显示，不处于则隐藏。因此纽约和悉尼不应全年同时显示；判断必须使用当前时刻和 IANA 规则，不能继续读取 23 项手工名单。

本地代码现状：

模块	当前实现	问题
时区源列表	`time_zone_describe.json` 静态维护 266 项 label 和 value	label 中混入固定 GMT、标准/夏令名称，无法自动适应规则变化
时区接口	`PersonnelRestService#getAllTimezones` 返回 label、value、simpleLabel、`supportsDST`	`supportsDST` 来自手工名单，表达能力而非当前状态；无法正确控制季节性标签
DST 判断	`OrganizationConfigCoreService` 使用 23 项配置名单做 `contains` 判断	名单与 IANA 2026c 规则存在 68 项差异，也没有结合当前时刻判断
Web 展示	`language_setting/index.vue` 直接以 `supportsDST` 控制“已支持夏令时”	将“是否支持”误当成“当前是否生效”，导致悉尼标准时段仍显示标签
对象时间换算	`RequestContext` 将时区解析为 `ZoneId`，`DateTimeDataConverter` 按会话时区格式化	已有正确方向，本期必须保证不受列表静态 GMT 文案影响
Android	`TimeZoneUtil` 使用当前 `getOffset(now)` 生成设备时区文案	与本期固定标准偏移的列表规则不一致，需要同步调整

对 266 项按 IANA 2026c 重新审计后：259 个 value 可以正常解析，其中包含 63 个合法 IANA Link；另外 7 个是不能直接迁移的特殊 value。按统一标准偏移和中性名称生成目标标签后，180 项需要调整。详细结果见配套 Excel：[时区目录与DST展示优化_266项逐条整改表_IANA2026c_20260804.xlsx](时区目录与DST展示优化_266项逐条整改表_IANA2026c_20260804.xlsx)。

1.3 竞品现状

先区分两个概念：下表中的“偏移规则”只说明时区选择列表里的 GMT/UTC 数字怎么展示；用户选中时区后，日程、日期时间字段等业务时间仍应按照目标时刻的 IANA 规则动态换算。

产品	可核实目录数量	列表单项展示格式	列表偏移规则	搜索特点	证据结论与本需求取舍
纷享销客现状	266 个固定选项	`GMT偏移 + 时区名称 + IANA ID`	静态混合，当前问题：悉尼固定成夏令时 `GMT+11`，纽约固定成标准时间 `GMT-05`，全表没有统一口径	主要搜索现有 label；没有中文城市词时搜不到	来源：本地配置和用户截图。证明：现有列表同时混用了标准偏移和夏令时偏移。不能证明：列表文字不能代表实际业务换算结果。本期取舍：统一改成标准偏移，并补充本地化城市搜索。
Outlook	可核实 139 个 Windows 逻辑时区 ID；不是城市总数	`UTC标准偏移 + 城市/城市组`；搜索建议右侧可带 `EST/CST` 等缩写	标准偏移（静态）：纽约在夏令时期间仍显示 `UTC-05`，悉尼显示 `UTC+10`；普通季节切换不改列表数字	城市可映射到一个逻辑时区	来源：用户截图、[Windows 默认时区](https://learn.microsoft.com/windows-hardware/manufacture/desktop/default-time-zones)。<br />证明：纽约和悉尼采用标准偏移展示。不能证明：两个城市不能代表所有法规特殊地区。本期取舍：采用其稳定标准偏移方案。
Google Calendar	官方未公布稳定的前台选项数；API 接受 IANA ID	`GMT当前偏移 + 本地化时区名称 + 城市`	当前实际偏移（动态）：截图时纽约处于夏令时，显示 `GMT-04`；悉尼处于标准时间，显示 `GMT+10`	支持按城市或国家搜索并映射到时区规则	来源：用户截图、[Google Calendar 更新说明](https://workspaceupdates.googleblog.com/2026/03/easily-find-and-set-time-zones-in-Google-Calendar-by-searching-for-city-or-country.html)。<br />证明：截图时点显示当前实际偏移，并支持本地化城市搜索。不能证明：不能仅凭截图判断内部存储和全部页面实现。本期取舍：借鉴城市搜索，不采用动态列表偏移。
Slack	官方未公布稳定的前台选项数	`UTC标准偏移 + 城市/城市组`	标准偏移（静态）：北美 8 月处于夏令时，Eastern Time 仍显示 `UTC-05`、Atlantic 仍显示 `UTC-04`	支持下拉选择和设备自动设置；搜索索引未公开	来源：用户截图、[Slack User object](https://docs.slack.dev/reference/objects/user-object/)。<br />证明：选择器展示标准偏移；用户实际 `tz_offset` 会随 DST 动态变化。不能证明：官方未公布完整目录数量和标签生成方式。本期取舍：支持“列表标准偏移、业务换算动态偏移”的方案。
飞书	官方未公布稳定的前台选项数	`GMT当前偏移 + 本地化时区名称 + 城市`	当前实际偏移（动态）：截图时纽约显示夏令时 `GMT-04`，悉尼显示标准时间 `GMT+10`	支持按本地化城市搜索	来源：用户截图。证明：截图时点使用当前实际偏移和本地化城市名称。不能证明：未公开完整目录数和内部存储模型。本期取舍：借鉴城市优先展示和搜索，不采用动态列表偏移。

竞品结论： Outlook、Slack 的选择器采用标准偏移（静态）；Google、飞书采用当前实际偏移（动态）；纷享销客当前则是静态但口径混合。本期采用 Outlook/Slack 的列表方案：列表固定展示标准偏移，普通夏令时切换不改 GMT；实际业务时间继续按 IANA 规则动态换算。

目录数量结论： IANA 和 CLDR 都没有规定国际产品必须展示多少个城市。IANA 提供计算规则，CLDR 提供本地化名称；它们不是前台菜单。现有 266 个选项不需要机械扩成全部 IANA 名称，但也不能只在客户投诉后被动增加。本期按“标准主 ID、设备同步、重点市场、独立规则缺口”四项标准主动补齐一组高优先级城市；其他合法 IANA ID 由后台完整识别并分批开放。

1.4 产品价值

让用户可以稳定理解列表中的 GMT：它始终代表该时区的标准偏移，不会因季节变化导致列表重排或文案漂移。
将“列表怎么写”和“业务时间怎么算”彻底分开，避免静态文案参与换算造成真实时间错误。
仅在当地当前处于夏令时期间显示状态，避免把“支持能力”误解为“当前生效”。
补齐合法城市/IANA ID，解决 Zurich 等设备同步和搜索失败。
保留合法 IANA Link 和用户选择的地点语义，避免为了所谓“标准化”错误迁移历史 value。

1.5 需求目标

用户打开时区选择列表时，266 个现有选项统一展示当地标准偏移和不随季节变化的中性名称；夏令时季节切换不修改列表 GMT。
用户选中时区后，仅当该时区在当前时刻处于夏令时期间时显示“当前为夏令时”；退出夏令时后自动隐藏。实际时间换算按业务目标时刻应用真实规则，不固定假设为 1 小时。
日期时间字段、日程、提醒和接口继续按目标日期对应的当地规则换算；列表中的 GMT、名称和夏令时提示只用于用户识别，不参与时间计算。
后端能够识别合法 IANA ID；前台目录不机械扩成全部 IANA 名称，本期主动新增 10 个高优先级城市/地区，后续按设备同步命中、目标市场和独立规则缺口分批开放。

二、产品方案

2.1 整体产品方案

本期保留现有时区选择入口和 266 项目录。对用户可感知的改动只有以下四项：

改动点	调整后的产品规则	本期不做什么
列表展示	统一展示`(GMT±HH:MM) 本地化城市（中性时区名称）`；GMT 固定使用当地标准偏移	不因进入或退出夏令时而修改 GMT、重排列表
搜索	列表展示的`(GMT±HH:MM) 本地化城市（中性时区名称）`均可被检索到	不要求普通用户理解或输入英文技术值
夏令时提示	仅当所选地区当前正处于夏令时期间时显示“当前为夏令时”	不再全年显示“已支持夏令时”，也不使用旧手工名单判断当前状态
目录补齐	本期新增 10 个高优先级城市/地区，既覆盖已反馈的苏黎世，也主动补齐东南亚、澳大利亚、欧洲和中东的明显缺口；现有合法时区值继续兼容	不一次性把全部目录差异都铺到前台，也不批量迁移历史 value

用户侧主流程可概括为：搜索“悉尼” → 看到(GMT+10:00) 悉尼（澳大利亚东部时间） → 选择并保存。列表保持稳定；如果悉尼当前正处于夏令时，再单独显示状态提示。日期时间字段和日程仍按目标日期的真实当地时间换算，不读取列表中的 GMT 数字。

2.2 具体方案说明

2.2.1 时区列表展示

统一采用一行用户可读文案：

(GMT±HH:MM) 本地化城市/地区（中性时区名称）

组成部分	规则
GMT 偏移	固定展示目录生效日期对应的当地标准偏移，不随普通夏令时月份变化；国家永久调整标准时间时按法规生效日切换
城市/地区	使用当前界面语言的城市/地区名；中文显示“悉尼”，英文显示“Sydney”。城市名是用户搜索和选择地点的主要入口
时区名称	优先使用 CLDR generic/location 名称；不再静态写入会随季节失真的“夏令时间”名称
系统识别码	IANA ID 不在普通用户界面展示；系统内部继续保留，并允许输入完整 ID 时精确搜索命中
排序	按标准偏移排序；同一偏移内按本地化名称排序，不因夏令时切换跳序

典型目标结果：

IANA ID	中文主行	英文主行	当地夏令时期间实际偏移
`America/New_York`	`(GMT-05:00) 纽约（北美东部时间）`	`(GMT-05:00) New York (Eastern Time)`	`UTC-04:00`
`Australia/Sydney`	`(GMT+10:00) 悉尼（澳大利亚东部时间）`	`(GMT+10:00) Sydney (Australian Eastern Time)`	`UTC+11:00`
`Europe/Zurich`	`(GMT+01:00) 苏黎世（中欧时间）`	`(GMT+01:00) Zurich (Central European Time)`	`UTC+02:00`
`Asia/Kolkata`	`(GMT+05:30) 加尔各答（印度时间）`	`(GMT+05:30) Kolkata (India Time)`	不适用，全年`UTC+05:30`
`Australia/Lord_Howe`	`(GMT+10:30) 豪勋爵岛（豪勋爵岛时间）`	`(GMT+10:30) Lord Howe Island (Lord Howe Time)`	`UTC+11:00`，只调整 30 分钟
`Africa/Casablanca`	2026-09-20 前为`(GMT+01:00) 卡萨布兰卡（摩洛哥时间）`；从生效时刻起为 `GMT+00:00`	同规则	以 tzdb 法规规则为准

这里增加本地化城市名，不是再造一层时区数据。现有“澳大利亚东部时间”描述的是一组时区规则，不能直接回答用户“我要选择哪个城市”；而中文用户通常会搜索“悉尼”。当前列表只包含英文 value Australia/Sydney 时，用户搜索“悉尼”无法命中，就会误以为系统缺少悉尼时区。因此目标文案把城市放在前面、时区名称放在括号中；如果城市名与时区名称实质重复，可合并为一个名称，避免机械重复。

保存值仍是 IANA ID，但它属于系统内部标识，不需要暴露给普通用户。中文用户输入“悉尼”、英文用户输入“Sydney”，或设备同步传入 Australia/Sydney，都应命中同一条并保存同一个 value。

“固定标准偏移”不等于提前采用未来偏移，也不等于永远不更新。国家永久修改标准时间时，标签必须按 tzdb 记录的生效时刻切换。例如 IANA 2026c 已记录 Alberta 自 2026-06-18 起永久使用 UTC-06:00；Africa/Casablanca 在 2026-09-20 02:00 前仍为 UTC+01:00，从该时刻起永久改为 UTC+00:00。因此，摩洛哥不能在法规生效前提前改成 GMT+00:00。[IANA 2026c Africa 规则](https://data.iana.org/time-zones/tzdb-2026c/africa)

2.2.2 夏令时状态标记

“该地区会不会实行夏令时”和“该地区现在是不是夏令时”是两件事。界面只需要表达当前状态：

场景	界面表现
当前正处于夏令时期间	在已选时区下方显示“当前为夏令时”
当前不处于夏令时期间	不显示夏令时标签，即使该地区一年中的其他月份会实行夏令时
该地区全年不实行夏令时	不显示夏令时标签

例如 2026-08-04，纽约显示“当前为夏令时”，悉尼不显示；到悉尼进入当地夏季后，两者的显示状态会随各自规则变化。系统需要按当地规则判断，不能简单假设所有地区都是固定加 1 小时；豪勋爵岛只调整 30 分钟，摩洛哥等地区也存在特殊规则。具体字段名、接口结构和缓存方式由研发设计，产品验收只看状态是否在正确日期出现和消失。

1785915630767

2.2.3 实际时间换算

业务换算规则不读取列表中的 GMT 文案：

实际显示时间 = UTC 时间戳 + selectedZoneId 在该目标时刻对应的 ZoneRules 偏移

例如纽约列表常年显示 GMT-05:00，但 2026 年 7 月的日期时间字段应按 UTC-04:00 展示；悉尼列表常年显示 GMT+10:00，当地夏季的业务时间应按 UTC+11:00 展示。

对象日期时间现有代码已经通过 ZoneId 格式化，本期保持该方向。研发需要确认所有日期时间字段、时间字段、日程、提醒、导入导出和开放接口均未使用 label 中的 GMT 数字做固定平移。

2.2.4 现有 266 个时区列表的错误值 value 待处理

先区分 IANA Zone 和 Link：

Zone 是直接记录历史与未来时钟变化规则的时区名称，例如 America/New_York。
Link 是 IANA 官方维护、指向某个 Zone 的兼容名称，例如旧名称或同规则地点。Link 仍是合法时区标识，不是错误数据。
Link 只证明两者按 tzdb 使用同一套计算规则，不证明两个城市是同一个地点。因此系统可以在内部解析到同一规则，但不能为了“统一 value”覆盖用户原来选择的城市。

分类	数量	目标动作	原因
IANA Zone	196	保留 value，只更新标签和 DST 规则	已是 IANA 正式 Zone
IANA Link	63	保留 value，不因 Link target 强制迁移	Link 本身是合法 timezone name，规则关联不等于地点相同
特殊 value	7	停止新增、历史兼容读取，逐条验证后再决策	不存在统一官方 Link 依据，直接替换可能改变地点或历史时间语义

这里的“停止新增”只表示新用户不再从选择器写入这些非标准值，不表示删除历史数据。已有人员设置、历史记录和接口入参必须继续兼容读取；只有完成存量数量、最早业务日期、运行库解析和外部接口回归后，才允许讨论迁移。

当前 value	为什么特殊	为什么不能直接替换	新用户怎么处理	历史数据怎么处理	主要风险
`Asia/Isfahan`	当前 IANA 2026c 核心 Zone/Link 中没有该名称；伊朗代表规则是`Asia/Tehran` 被德黑兰替代	伊斯法罕和德黑兰是不同城市，IANA 没有官方 Link 证明二者是同一个 value	搜索伊朗/伊斯法罕时引导选择受支持的伊朗规则，并保留城市搜索词	原值继续可读；核对存量、历史日期和运行库结果后再决策	直接替换会改变地点语义
`Asia/Hanoi`	河内只存在于可选历史`backzone`；现代核心目录不把它作为独立 Zone 被胡志明替代	IANA 说明北越自 1970 年起使用`Asia/Bangkok`；越南全国仅自 1975-06-13 起与 `Asia/Ho_Chi_Minh` 一致，不能全量改成胡志明市	搜索“河内/越南”时提供现代可用结果，并明确所采用的代表规则	原值继续可读；按时间范围保留历史解释，不静默迁移	直接改胡志明市会错误解释 1970-1975 的历史时间
`America/Ciudad_del_Este` 巴拉圭已经统一成一个时区了，这个时区作废了	当前 IANA 核心目录只列巴拉圭代表规则`America/Asuncion`	东方市和亚松森是不同城市，二者不是官方 Link	新用户选择巴拉圭代表规则；东方市作为搜索别名	原值兼容读取，核对历史时间后再决定是否映射	地点语义变化，历史规则等价性未被 Link 保证
`America/Cusco` 秘鲁已经合并成一个标准时区了，这个作废	当前 IANA 核心目录只列秘鲁代表规则`America/Lima`	库斯科和利马是不同城市，二者不是官方 Link	新用户选择秘鲁代表规则；库斯科作为搜索别名	原值兼容读取，核对历史时间后再决定是否映射	地点语义变化
`Pacific/Santo` 原因同上	当前 IANA 核心目录只列瓦努阿图代表规则`Pacific/Efate`	Santo 与 Efate 是不同岛屿/地点，二者不是官方 Link	新用户选择瓦努阿图代表规则；Santo 作为搜索别名	原值兼容读取，核对历史时间后再决定是否映射	地点语义变化，早期规则可能不同
`Asia/Ulan_Ude` 原因同上	当前 IANA 由`Asia/Irkutsk` 覆盖 Buryatia 地区	乌兰乌德和伊尔库茨克是不同城市，而且当前旧标签为`GMT+09`，候选规则为 `GMT+08`	暂不允许新写入，先修正/确认规则和标签	原值继续可读，必须专项核对现有一小时差异后再处理	直接替换可能让业务时间变化 1 小时，风险最高
`Asia/Chelyabinsk` 原因同上	当前 IANA 由`Asia/Yekaterinburg` 覆盖 Chelyabinsk Oblast	车里雅宾斯克和叶卡捷琳堡是不同城市，二者不是官方 Link	新用户选择受支持的区域代表规则；保留城市搜索词	原值兼容读取，完成历史和接口回归后再决策	地点语义变化，不能把区域覆盖说明当成迁移指令

结论不是“删除 7 条数据”，而是：阻止继续产生新的非标准值，同时保护已有数据；其中任何一条都不在本期做无条件批量替换。逐条官方依据、文件行号和候选规则见 Excel 的特殊值兼容工作表。

逐条目标、标签、DST 差异和依据以配套 Excel 为准：

实施总览：研发本期需要完成的范围、数量和统一规则
标签调整：266 个现有选项逐条调整后的标准偏移、城市和中性时区名称
夏令时范围调整：仅列出 68 个需要修改夏令时支持状态的选项，其中 67 个新增支持、1 个取消支持
本期新增10项：本期必须新增的 10 个时区及其标签、标准偏移和夏令时规则
特殊值兼容：7 个非标准 value 的新写入限制和历史兼容方案

2.2.5 时区列表增加与搜索体验

IANA 没有规定“国际产品必须展示多少个城市”。本方案用 zone1970.tab 的 312 个代表规则作为后端计算覆盖审计基线，用 CLDR 的本地化城市/时区名称作为展示与搜索词来源。当前 266 项覆盖 206 个代表规则，审计发现 116 个目录差异，但“有差异”不等于“116 项全部加入前台”：

缺口类型	数量	含义	本期结论
标准主 ID 缺失	10	已有其他地点/旧别名可提供等价规则，但标准城市 ID 不可直接选择，如`Europe/Zurich`、`Australia/Hobart`、`Europe/Kyiv`	需要增加
独立规则完全缺失	106	当前 266 项中没有能够完整代表该地区 1970 年后规则的选项	后续按客户反馈逐批增加，非本期范围

泰国与越南专项核验：

国家/地区	当前已有 value	IANA 2026c 结论	是否需要新增	本期动作
泰国	`Asia/Bangkok`	泰国现代标准时区完整，全年`UTC+07:00`，不实行夏令时	不需要	保留 value；增加“泰国/Thailand/曼谷/Bangkok”多语言搜索词
越南	`Asia/Ho_Chi_Minh`	越南现代时区完整，全年`UTC+07:00`，不实行夏令时	不需要新增现代时区	保留 value；增加“越南/Vietnam/胡志明市/Ho Chi Minh City”搜索词
河内历史值	`Asia/Hanoi`	不是当前核心 Zone/Link；北越自 1970 年按`Asia/Bangkok`，1970 年前规则在可选 `backzone`	不作为新 value 新增	历史兼容；“河内/Hanoi”参与搜索，但不得静默改为`Asia/Ho_Chi_Minh`

因此，泰国和越南当前不是“没有时区”，问题主要是国家/城市搜索词不全，以及Asia/Hanoi旧值的历史兼容。两国均不涉及夏令时动态偏移。

目录不能只靠客户反馈补洞。本期采用以下准入标准：

标准主 ID： 操作系统、浏览器或设备可能直接返回，缺失会导致同步失败。
重点市场： 国家、首都或大型区域具有明确用户识别价值。
独立规则： 当前 266 项没有任何其他 value 能正确代表当地规则，缺失可能直接造成时间错误。
搜索可达： 即使不增加新的 value，也要让国家、城市、本地语言和英文名称命中正确时区。

本期范围建议：

P0 前台主动新增 10 项： Europe/Zurich、Europe/Kyiv、Asia/Yangon、Asia/Kuching、Australia/Hobart、Asia/Qatar、Pacific/Port_Moresby、Asia/Makassar、Asia/Jayapura、Asia/Amman。前 7 项解决标准主 ID/设备同步和主要城市缺口，后 3 项补齐当前完全缺失的独立规则；其中 Makassar、Jayapura 分别覆盖印度尼西亚中部和东部，不能用现有 Asia/Jakarta 代替。
P0 后端： 合法 IANA ID 不再被固定 266 白名单拒绝；外部/设备返回未开放 ID 时可保存和回显标准名称，或给出明确兼容提示。
P1 下一批候选： America/Cancun、Atlantic/Canary、Atlantic/Madeira、Indian/Mauritius、Europe/Malta、Asia/Nicosia。这些都是国家/地区或重要区域的独立规则，应结合海外客户分布和设备同步命中量安排下一批，不必等到投诉后才开始分析。
P2： 其余缺口继续保留在审计表中；后台完整识别，前台按国家/地区市场包分批开放。Pacific/Kanton 等低频标准主 ID 不在默认浏览列表优先铺开，但应支持精确 ID 搜索和设备同步。

2.2.6 兼容与影响范围

位置	兼容策略
历史人员时区值	259 个合法值保持不变；7 个特殊值继续可读，不静默批量更新
API	现有接口保持兼容，并补充界面判断当前夏令时状态、完成多语搜索所需的信息；具体字段由研发设计
Web	列表使用固定标准偏移；只在当前处于夏令时期间显示状态标签；支持城市、国家和内部 ID 精确搜索
Android/iOS	与 Web 统一标准偏移展示；设备当前偏移只用于“检测到设备时区”提示
日期时间字段	保持按用户/租户`ZoneId` 和目标时间戳格式化，不读取列表 label
导入导出/开放接口	继续兼容历史 value；特殊值迁移前必须按真实时间戳回归

2.3 待确认事项

ID	待确认事项	影响范围	负责人	结论
1	当前状态标签是否将“已支持夏令时”改为“当前为夏令时”	多语言词条、Web/移动端	产品	建议改名；显隐规则已确认按当前状态
2	目标版本是否早于 2026-09-20，以确定摩洛哥首次发布时显示`GMT+01:00` 还是 `GMT+00:00`	初始数据、测试用例	产品/研发	待确认
3	服务端 Java、Web ICU、Android/iOS 当前使用的 tzdb 版本和统一升级机制	规则一致性	研发	待确认
4	7 个特殊 value 的线上存量、最早业务日期和外部 API 使用情况	历史迁移	研发/数据	待查询，未完成前不迁移
5	后端对“合法但未在前台开放”的 IANA ID，是直接保存回显，还是提示用户选择已开放代表项	设备同步、API 兼容	产品/研发	建议直接保存回显，避免继续受 266 白名单限制
6	后续前台开放项的市场优先级和批次	目录长期治理	产品	本期先交付 10 个 P0；后续结合设备同步命中量、客户分布和目标市场包滚动开放

三、规范检查项

3.1 业务文案多语言 Key

模块	功能点	示意图	中文	英文	多语言 Key
时区选项	266 项城市名与中性时区名称	见 1.3 截图	按配套 Excel 维护本地化城市和中性名称	按 CLDR exemplar city 与 generic/location 名称维护	沿用现有时区选项词条并补齐城市搜索词
个人设置	夏令时当前状态标签	见 1.3 截图	当前为夏令时	Daylight saving time is currently in effect	建议新增 current-state key；旧 key 仅作兼容

IANA Zone ID 不翻译、不作为用户可见文案；系统内部继续保留。词条调整前必须确认目标 value 与当前地点含义一致，不能通过翻译词条掩盖 value 迁移。

3.2 需求埋点

无新增产品埋点。本期为既有设置项的规则纠偏，优先通过服务日志和异常监控验证。

3.3 沙盒/更改集能力

模块	功能点	是否支持沙盒	是否支持更改集	说明
个人时区设置	时区目录和 DST 状态	不涉及	不涉及	属于系统预置目录与个人设置，不作为企业配置迁移

3.4 PaaS 国际化兼容检查

ID	多语接入事项	是否需要	注意事项
1	接入翻译工作台	否	沿用现有预置多语词条维护方式，不新增用户可编辑翻译配置
2	CRM提醒	否	提醒时间换算需回归，但不新增提醒内容
3	企信消息提醒	否	不新增消息内容
4	修改记录	否	个人时区修改沿用现有记录能力
5	审计日志	否	不新增用户可见审计类型
6	支持快捷翻译能力	否	无用户输入文案
7	支持数据多语能力	否	IANA ID 为语言无关标识，展示名称使用预置多语词条
8	预置配置多语	是	现有 266 项及新增 Zurich 的城市名、中性名称和状态标签需同步维护中英文及其他现有语言
9	预置示例数据多语	否	不涉及示例数据

3.5 新对象/新字段 BI 分析申请

对象/字段	是否已做流程支持申请	是否已做 BI 分析申请	内容
无新增业务对象/业务字段	不涉及	不涉及	新增内容为时区接口返回字段，不进入业务对象和 BI 模型

3.6 操作日志说明

不新增用户可见操作日志。服务端应记录 tzdb 版本、无法解析的 Zone ID、特殊 value 兼容命中以及服务端/客户端规则版本不一致，供问题排查使用。

3.7 需求风险点检测

ID	风险分组	风险类型	有无该风险	涉及风险的功能点	影响的企业数	是否报备	响应策略
1	对现逻辑有影响的风险点	交互体验有变化	有	180 项时区文案调整、夏令时标签改为当前状态	使用多时区能力的企业，具体数量待查询	是	灰度发布，提供典型城市前后对照
2	对现逻辑有影响的风险点	功能有减少	无	无	无	否	不涉及
3	对现逻辑有影响的风险点	功能逻辑的调整	有	手工 DST 名单改为规则库、Web/移动端统一	使用多时区能力的企业，具体数量待查询	是	跨端统一 tzdb 版本并覆盖重点测试用例
4	新能力风险点	逻辑不完善	有	7 个特殊 value 和都柏林/摩洛哥特殊规则	存量待查询	是	停止新增、保留旧值、逐条回归，不直接批量迁移
5	新能力风险点	有性能压力	低	判断当前夏令时状态、增加多语城市搜索	全部时区列表请求	否	标准标签预生成；状态和搜索结果需通过性能回归

3.8 上线策略

3.8.1 收费标准

[X] 不收费
[ ] 收费

本需求为现有多时区能力的正确性和国际化治理，不新增独立收费能力。

3.8.2 上线节奏

[ ] 全网
[X] 灰度

灰度发布的原因	涉及 266 项展示、DST 规则来源和多端一致性；需要先验证历史 value、跨季节时间和客户端版本差异
预计全网时机	灰度完成且重点时区、对象日期时间、日程与接口回归通过后，具体日期待排期
期间分几次灰度	建议 3 次：内部企业、海外重点客户、小范围扩量
各灰度批次的时间节点及灰度的客户范围	待研发排期和客户范围确认；7 个特殊 value 存量企业应单独纳入观察名单

3.8.3 适用版本

资源名称	标准版	专业版	旗舰版	无限版	扩展资源包
多时区目录与 DST 展示优化	沿用现有多时区能力范围，待确认	沿用现有多时区能力范围，待确认	沿用现有多时区能力范围，待确认	沿用现有多时区能力范围，待确认	不新增

四、依据与配套材料

[266 项逐条整改 Excel](时区目录与DST展示优化_266项逐条整改表_IANA2026c_20260804.xlsx)
[IANA Time Zone Database 2026c](https://www.iana.org/time-zones/releases/2026c)
[Unicode TR35 - Time Zone Names](https://unicode.org/reports/tr35/tr35-dates.html)
[Microsoft BaseUtcOffset](https://learn.microsoft.com/dotnet/api/system.timezoneinfo.baseutcoffset)
[Microsoft 默认时区列表](https://learn.microsoft.com/windows-hardware/manufacture/desktop/default-time-zones)
[Microsoft Graph supportedTimeZones](https://learn.microsoft.com/graph/api/outlookuser-supportedtimezones?view=graph-rest-1.0)
[Unicode CLDR Windows-IANA 映射](https://github.com/unicode-org/cldr/blob/main/common/supplemental/windowsZones.xml)
[Google Calendar 2026 城市/国家搜索更新](https://workspaceupdates.googleblog.com/2026/03/easily-find-and-set-time-zones-in-Google-Calendar-by-searching-for-city-or-country.html)
[Google Calendar API Events](https://developers.google.com/workspace/calendar/api/v3/reference/events)
[Slack 时区设置](https://slack.com/help/articles/219889247-Manage-your-time-zone-preferences)
[Slack User object：tz_offset 会随夏令时变化](https://docs.slack.dev/reference/objects/user-object/)
[IANA theory：zone1970.tab 与时区命名](https://www.iana.org/time-zones/theory)
[CLDR Time Zones and City Names](https://cldr.unicode.org/translation/time-zones-and-city-names)
fs-social-feeds/fs-social-organization/src/main/resources/personnel/time_zone_describe.json
fs-social-feeds/fs-social-organization/src/main/java/com/facishare/social/organization/predefine/service/PersonnelRestService.java:259
fs-social-feeds/fs-social-organization/src/main/java/com/facishare/social/organization/service/OrganizationConfigCoreService.java:114
xxvui/src/async_components/language_setting/index.vue:104
fs-paas-appframework/fs-paas-app-api/src/main/java/com/facishare/paas/appframework/core/model/RequestContext.java:223
fs-paas-appframework/fs-paas-app-metadata/src/main/java/com/facishare/paas/appframework/metadata/dataconvert/DateTimeDataConverter.java:40
fs-android/lib/metadata-sdk/src/main/java/com/facishare/fs/metadata/utils/TimeZoneUtil.java:124