日期适配器引入之后，最需要重看的是那些平时很少出现、出了问题却很难排查的输入。施工项目的周视图以星期一作为开始，活动任务跨十月与十一月；与此同时，操作记录有准确时分秒，部分管理人员还会从不同时区查看进度。假如把自然日和时间戳都转换成同一类Date对象，再根据设备时区格式化，十月三十一日的隐蔽验收很容易在另一个时区显示成十月三十日。

上一节把第三方Day.js限制在明确的日期端口之内，这一节进一步固定时间含义。计划字段startDay与endDay存自然日，含义由项目日历规定；操作时间updatedAt存绝对时刻，并记录需要时的项目时区。日期比较只比较经过严格验证的自然日索引，操作事件排序则依据时间戳。把这两条路径拆开后，跨月、闰年和夏令时都能独立定位。

自然日与时间戳不能互换

同一个施工日可能对应多个实际时刻。例如上海时区的十一月一日零点，对应UTC十月三十一日十六点。若直接截取这个时间戳的前十位，就会错误显示十月三十一日；若原字段本来就是2026-10-31，再附上时区偏移转换，也可能让它变成其他日期。两种错误看起来相似，解决路径却完全不同。前者需要按项目时区格式化时刻，后者应保留自然日原值。

在项目数据中，ACT-01基础准备是十月二十七日，ACT-02混凝土浇筑是二十八日至三十日，ACT-03钢筋安装是二十九日至三十一日，ACT-04隐蔽验收是十月三十一日的单日里程碑。所有活动的日期均为规范化字符串，在周图里面允许跨月份展示，却不能因为网络请求执行地点不同而移动。维护这份稳定模型，比在每个图表组件里写一次new Date()更有效。

界面输出还应标明显示的到底是计划日还是记录时间。计划日不需要附带“上午八点”的无关描述；现场修改的审计记录则必须保留明确的时间戳。项目在不同终端打开时，日历周范围与任务起止保持不变，而“最后修改时间”可以按照用户选择的显示时区换算。

先约束日期输入，再计算边界

要解决的问题是避免JavaScript日期构造器自动归一非法输入。Date.UTC(2026,1,29)会滚动到三月，因此必须将生成的日期重新格式化并与原文比较。将日历日期映射为UTC日序数是为了做稳定整数计算，并不意味着这个施工自然日属于UTC时区。下面是完全独立于第三方包的Node.js业务计算实现，也可作为日期适配器的参照算法。

const DAY_MS = 86400000;
function dayIndex(value) {
  if (typeof value !== 'string' || !/^\d{4}-\d{2}-\d{2}$/.test(value)) {
    throw new RangeError('施工日期格式无效');
  }
  const [y, m, d] = value.split('-').map(Number);
  if (y < 1900 || y > 2100) throw new RangeError('年份超出约定范围');
  const millis = Date.UTC(y, m - 1, d);
  if (new Date(millis).toISOString().slice(0, 10) !== value) {
    throw new RangeError('施工日期不存在');
  }
  return millis / DAY_MS;
}
function addDays(value, amount) {
  if (!Number.isInteger(amount)) throw new RangeError('天数必须为整数');
  return new Date((dayIndex(value) + amount) * DAY_MS)
    .toISOString().slice(0, 10);
}
function monday(value) {
  const index = dayIndex(value);
  return new Date((index - (index + 3) % 7) * DAY_MS)
    .toISOString().slice(0, 10);
}
module.exports = { dayIndex, addDays, monday };

2024-02-29可以成功解析，2026-02-29应进入错误分支；2026-10-31加一天得到2026-11-01，2026-12-31加一天得到2027-01-01。monday('2026-11-01')返回2026-10-26，与施工周视图左侧表头吻合。这段日序数逻辑适合做固定自然日距离与区间比较，但不处理某个城市的当地钟表时间。

还要考虑输出格式。2026-10-9虽然直观，和2026-10-09在字典序比较时却不是同一契约；2026/10/09也不在当前输入协议中。列映射需要在进入日期服务之前完成，避免业务计算器承担多种非结构化数据格式的猜测工作。

时区转换只作用于绝对时刻

实际修改时间通常来自服务端事件，例如2026-10-31T16:00:00Z。用Intl.DateTimeFormat显式指定Asia/Shanghai后，可以得到十一月一日零点。这不是对活动计划日期的修改，而是把同一瞬间转换为项目所在地的读数。不要把转换后得到的日期再回写到活动的startDay字段。

function localClock(isoInstant, timeZone) {
  const millis = Date.parse(isoInstant);
  if (!Number.isFinite(millis) || !/Z$|[+-]\d{2}:\d{2}$/.test(isoInstant)) {
    throw new RangeError('事件时间需明确时区偏移');
  }
  const parts = new Intl.DateTimeFormat('en-CA', {
    timeZone, year: 'numeric', month: '2-digit', day: '2-digit',
    hour: '2-digit', minute: '2-digit', hourCycle: 'h23'
  }).formatToParts(new Date(millis));
  const fields = Object.fromEntries(parts.map(p => [p.type, p.value]));
  return `${fields.year}-${fields.month}-${fields.day} ${fields.hour}:${fields.minute}`;
}
console.log(localClock('2026-10-31T16:00:00Z', 'Asia/Shanghai'));
// 期望输出：2026-11-01 00:00

时区转换本身也有不同类型的输入。一种是已经有准确UTC时间戳的事件，转换到指定城市是单值问题；另一种是用户输入“当地时间十一月一日凌晨一点半”，在实行夏令时调整的地区可能对应两个绝对时刻。后一种输入要么要求用户补充偏移量，要么采用经过业务确认的消歧规则。不能把“当天一点半”随意视为唯一的时间戳。Node.js的Intl需要部署环境提供相应时区数据库，工程依赖记录里应明确运行环境版本。

对工程实践来说，测试样本不必铺成几百页，但要覆盖真正分岔的地方：闰年与平年，二月末与三月初，十月与十一月跨月，十二月与次年元旦，时区转换后自然日变化，还有本地时间重复或者跳过的夏令时边界。把每个样本的业务含义写清楚，出现异常时才知道应该查解析契约、时区数据库还是页面渲染。

周图的活动关系仍应单独校验

日期能成功解析不意味着活动输入一定成立。单日里程碑允许开始结束相同；施工活动的结束日不得早于开始日；相同活动ID的修订事件要遵循版本比较，不应该在日期服务里偷偷合并。此前使用的ACT-02最新进度为50%、修订9，这里的校验只检查它是否仍然落在十月二十八日至三十日，不改写历史进度。

function checkActivities(items, dateMath) {
  const ids = new Set();
  const problems = [];
  for (const item of items) {
    try {
      if (ids.has(item.id)) throw new Error('活动编号重复');
      ids.add(item.id);
      if (dateMath.dayIndex(item.end) < dateMath.dayIndex(item.start)) {
        throw new Error('结束日早于开始日');
      }
    } catch (error) {
      problems.push({ id: item.id, reason: error.message });
    }
  }
  return { accepted: items.length - problems.length, problems };
}
const dates = require('./DateBoundary.cjs');
const activityRows = [
  { id: 'ACT-02', start: '2026-10-28', end: '2026-10-30' },
  { id: 'ACT-03', start: '2026-10-29', end: '2026-10-31' },
  { id: 'ACT-04', start: '2026-10-31', end: '2026-10-31' }
];
console.log(checkActivities(activityRows, dates));

三项活动会获得零条日期顺序问题。若加入2026-02-29或者错误的结束日期，problems应携带活动ID和短原因，页面可以在相应行展示可定位的提示。输入出错不应该使整个周图突然消失，更不应该把该活动写成另一个合法日期来消除报错。业务列表和错误详情分离，便于运营人员按原始记录修复。

页面生命周期与问题排查

在HarmonyOS界面层，日期核验结果是普通数据。进入页面可以读取当前项目日期契约及任务列表，查询完成后依据当前项目ID和请求代际更新状态；离开页面应释放订阅、清理定时刷新和取消过期请求。关闭页面不意味着删除日期计算规则，也不会抹去任务的业务历史。由于日期服务不保存窗口对象，它自身可以作为无状态模块复用，系统API调用则仍遵守各自的页面生命周期要求。

排查时我会把路径拆成三段：查看传入的原始字段是否满足YYYY-MM-DD，比较日序计算的期望值，随后验证显示层是否使用了项目时区。比如同一条时间戳在Asia/Shanghai得到十一月一日，在UTC得到十月三十一日，这属于显示区域差异；若施工日2026-10-31被改写，那是类型和数据契约的问题。两个结论不能互相替代。

第三方日期库的适配也应遵循这一原则。Day.js端口处理输入与格式，Node内置日序算法提供独立的边界参照；两者应对同一批严格自然日给出相同结果。之后如果升级日期库，先运行这些边界样本，再更新依赖锁和发布清单。页面上只显示有效的日期和值，内部原因在工程排查记录里留下足够的字段即可。

跨月显示不是在表格末端多画一列这么简单。真正可靠的做法是让自然日、时间戳、时区和活动版本各守自己的职责：施工日期不会跟着查看者的设备位置变化，审计时间能准确追溯事件发生时刻，周视图也能在十月底和十一月初保持连续。这个稳定的业务底座，才值得交给后续的回归与发布复核流程继续维护。

参考资料

• 华为开发者：ArkTS运行时概述
• 华为开发者：ArkTS简介
• 华为开发者：oh-package.json5依赖配置
• Day.js：UTC插件与时区语义