一张值班表如果只存“2026-10-25 01:30”，在某些城市会遇到很隐蔽的问题：这一串本地时间可能对应两个不同时刻。列表上看起来完全重复，业务上却是前后相隔一小时的两次交接。若客户端按照 日期 + 时分 去重，就可能把第二条值班记录删掉；如果统计又按 UTC 时刻计算，前后两个模块看到的总数还可能不一致。

本文选择葡萄牙里斯本的夏令时回拨日作为有边界的样例。2026 年 10 月 25 日，2026-10-25T00:30:00Z 与 2026-10-25T01:30:00Z 在 Europe/Lisbon 时区都可显示成当地的 01:30，但前者偏移为 +01:00，后者为 +00:00。ShiftClock 是说明这个问题的演示看板，并非已经接入排班系统的产品；两条记录使用 LSB-0130A 与 LSB-0130B 作为示例 ID。

一、一个看起来重复的时间，实际有两种含义

先区分三个词：UTC 时间戳代表绝对时刻；时区 Europe/Lisbon 代表某个地区随历史规则变化的显示规则；本地钟面时间 01:30 只是人看到的标签。同一天同一标签并不必然是同一个时刻。把三者压成一个字符串，问题迟早发生在排序、去重、通知触发或审计记录中。

从存储角度，后台应保存具有明确时区偏移的 ISO 8601 时刻或 Unix 时间戳，并保存事件业务 ID。展示层在需要时转换到用户选择的 IANA 时区。不要把 2026-10-25 01:30 当作充分的数据库主键，也不要默认每一天都是 24 个当地小时；切换日可能有被跳过或者被重复的小时。

这里使用 Day.js 的 utc 和 timezone 插件作为展示层适配。Day.js 官方说明时区功能依赖 Intl 支持，而且 timezone 插件依赖 utc 插件。这个前提在 HarmonyOS 上尤其要明确：不同目标运行环境的三方 JS 兼容性、国际化时区数据和插件行为都需要单独验证。文中没有假定某个未经核验的 Day.js 版本或某个 IDE 版本已经跑通。

二、先把时间适配关在一个小模块里

最容易审计的策略，是在进入页面前把两个 UTC 时刻归一化为视图模型，让页面只使用明确的显示字段。Day.js 接口不必散落在按钮回调、消息通知和本地数据库层。模块放在 entry/src/main/ets/utils/shiftTime.ts，ArkTS 页面调用一个经过静态类型约束的 TS/JS 兼容层；正式集成还要核对工程仓库可用的依赖版本与包类型声明。

下段代码只接收包含 Z 或明确偏移的绝对时刻，不接收没有偏移的本地字符串。插件顺序保持为先 utc 后 timezone，格式化时再明确指定目标时区。这样业务 ID 与本地展示时间之间不会产生不必要的耦合。

// entry/src/main/ets/utils/shiftTime.ts
import dayjs from 'dayjs';
import utc from 'dayjs/plugin/utc';
import timezone from 'dayjs/plugin/timezone';

dayjs.extend(utc);
dayjs.extend(timezone);

export interface SlotView {
  local: string;
  offset: string;
  iso: string;
}

export function formatSlot(utcIso: string, zone: string): SlotView {
  const instant = dayjs.utc(utcIso);
  if (!instant.isValid()) throw new Error('invalid UTC timestamp');
  const local = instant.tz(zone);
  return {
    local: local.format('YYYY-MM-DD HH:mm'),
    offset: local.format('Z'),
    iso: instant.toISOString()
  };
}

export function slotKey(utcIso: string): string {
  const instant = dayjs.utc(utcIso);
  if (!instant.isValid()) throw new Error('invalid UTC timestamp');
  return String(instant.valueOf());
}

formatSlot 的三个字段分别服务显示、歧义提示与审计追踪。slotKey 只使用绝对时刻生成技术去重键，并不负责业务排班事件的最终唯一性：如果同一时刻允许两个不同员工值班，最终主键仍应由业务 ID 决定。代码里的无效日期判断能拦截部分解析错误，但非法时区名、缺少 Intl 时区数据、运行时插件兼容问题仍需在外层捕获并回退成 UTC 展示，不能让页面空白。

也不能把 dayjs.tz('2026-10-25 01:30', 'Europe/Lisbon') 当作解决歧义的万能函数：原始值根本没告诉系统用户选的是回拨前还是回拨后，库不可能凭空恢复这个语义。更可靠的输入方式，是让服务端给出绝对时刻，或者在表单中显式要求用户选择 +01:00 / +00:00 两个选项。

三、让看板的两条记录都留下来

页面数据固定为两个不同 UTC 时刻。它们的本地时分完全相同，但是 iso、偏移值与业务 ID 不同。下段代码展示 ArkUI 的最小列表：ForEach 使用稳定的 ID 作为键，避免因文本同为 01:30 而错误地复用行状态。点击确认的网络写入不在此示例里，因为没有真实服务端，按钮仅作为未来交互位置。

// entry/src/main/ets/pages/ShiftBoard.ets
import { formatSlot, SlotView } from '../utils/shiftTime';

interface ShiftItem {
  id: string;
  label: string;
  utcIso: string;
}

@Entry
@Component
struct ShiftBoard {
  private zone: string = 'Europe/Lisbon';
  private items: ShiftItem[] = [
    { id: 'LSB-0130A', label: '班次 A · 夏令时',
      utcIso: '2026-10-25T00:30:00Z' },
    { id: 'LSB-0130B', label: '班次 B · 标准时间',
      utcIso: '2026-10-25T01:30:00Z' }
  ];

  build() {
    Column({ space: 16 }) {
      Text('ShiftClock · 跨时区值班看板').fontSize(22)
      Text('2026-10-25 · Europe/Lisbon')
      ForEach(this.items, (item: ShiftItem) => {
        Column({ space: 6 }) {
          Text(item.label).fontSize(18)
          Text(formatSlot(item.utcIso, this.zone).local)
          Text(`UTC 偏移 ${formatSlot(item.utcIso, this.zone).offset}`)
          Text(`ID ${item.id}`)
          Text('待确认')
        }.padding(16).width('100%').backgroundColor('#F4F0FF')
      }, (item: ShiftItem) => item.id)
      Text('唯一 UTC 时刻：2')
      Button('查看差异')
    }.padding(20).width('100%')
  }
}

实际大列表不应像这个可读示例一样，在一个构建过程中反复调用 formatSlot；可先把格式化结果缓存到视图模型，只有时区设置发生变化时才重新投影。SlotView 是用来表达模块返回形状的类型，是否在页面显式声明可按工程编译规则调整；切忌通过 any 隐藏第三方包的类型问题。对于数据条目较多的排班列表，还需评估懒加载和时区切换后的重绘成本。

四、去重键与业务主键必须分层

如果这个页面只有一条“在同一绝对时刻触发的提醒”，用 UTC 毫秒去重是合理的；但如果业务是排班任务，一个 UTC 时刻也可能对应多个岗位。正确思路是先明确“重复”的业务定义，再决定使用事件 ID、员工 + 岗位 + UTC 或幂等请求 ID。时间工具库只提供时间解释，不提供排班领域的唯一性规则。

为了避免将两个 01:30 错合并，下面的独立函数演示按 UTC 时刻做技术层去重。它不依赖界面，也不把时区字符串放进键中。若未来要按业务事件去重，应替换 slotKey 的使用场景，而不是继续扩大这个函数的职责。

// entry/src/main/ets/utils/deduplicate.ts
import { slotKey } from './shiftTime';

export interface SlotRecord { id: string; utcIso: string; }

export function distinctInstants(rows: SlotRecord[]): SlotRecord[] {
  const seen: Set<string> = new Set<string>();
  const result: SlotRecord[] = [];
  for (const row of rows) {
    const key: string = slotKey(row.utcIso);
    if (!seen.has(key)) {
      seen.add(key);
      result.push(row);
    }
  }
  return result;
}

对于示例中的两条记录，slotKey 的毫秒值应该不同，因此预期保留两条。这里没有编造一组真机耗时或已经通过的自动化测试数据。可以在工程里增加三种单元测试：同一 UTC 值重复两次应合并；两个不同 UTC 值虽然同为 01:30 应保留；非法日期和不支持的目标时区应走可见的错误分支。再附加春季跳时场景，检查那些根本不存在的本地时间如何处理。

还有一个潜在陷阱：旧日期库或不同运行时的时区规则实现可能存在夏令时边界差异，Day.js 社区也曾报告过相关问题。因此此处不把“代码理论上正确”偷换成“任意设备上的插件转换一定正确”。最终验收必须在目标 HarmonyOS SDK、具体设备系统版本与时区数据下，分别断言 UTC 和本地偏移，而且保留版本信息便于重现。

五、截图和产品行为到底能证明什么

手机效果图在日期标题下列出班次 A 与班次 B，两张卡都显示 01:30。第一张绑定 LSB-0130A、UTC 2026-10-25T00:30:00Z、偏移 +01:00；第二张绑定 LSB-0130B、UTC 2026-10-25T01:30:00Z、偏移 +00:00。底部写“唯一 UTC 时刻：2”。图片说明的是希望用户看到的目标 UI 状态，不是一个可由图片反推出真实时区计算结果的测试报告。

交互上不能靠颜色区分两个 01:30：色弱用户和读屏用户都需要文字化的偏移说明。待确认按钮应携带业务事件 ID，避免在列表调整位置之后写错对象。后台接受确认时还要校验版本号、用户身份和幂等键；前端去重只能避免展示错乱，不能代替持久层约束。

这套处理的边界也很明确：它适用于已有可信绝对时刻的值班展示。如果需求是用户手工选择“某天凌晨 01:30”并创建新任务，页面需要额外的歧义提示和可选偏移，不能直接以当前系统时区猜测；如果业务跨很多国家，还需要考虑当地时区规则历史变更、长期排班的重新计算以及离线设备的时区数据库版本。

从工程价值看，最值得保留的不是 Day.js 的一段格式化调用，而是“事件身份独立于本地标签”这条规则。两张外观一样的 01:30 卡片能否安全共存，取决于输入、存储、UI 键和确认请求是否都尊重绝对时刻。工具库只是把这个原则变成了可复用的代码接口。

资料： Day.js UTC 插件；Day.js Time Zone 文档；HarmonyOS oh-package.json5 依赖配置；HarmonyOS ArkTS 与 TS/JS 的互操作限制。