内容人员在北京时间23点40分发布文章，页面显示7月12日，Article JSON-LD却写成7月13日，sitemap的lastmod也提前了一天。生成脚本在服务器上读取UTC日期，再按另一套本地格式截取年月日。文章没有穿越，三个系统只是用不同的时区解释同一时刻。
发布时间应来自内容记录，不从部署机器的当前时间临时推算。后台保存published_at与modified_at，包含明确时区或统一使用UTC；页面展示时再转换到站点约定时区。构建脚本读取同一字段，生成HTML、Article数据和sitemap，避免各自调用“今天”。
ISO 8601时间要带偏移。只写2026-07-12T23:40:00，接收方不知道这是北京时间还是UTC。可写成带+08:00的时间，或保存为UTC的Z格式。若sitemap只输出日期，也应先按站点业务时区转换，再截取日期，不能先截UTC日期后转换。
发布时间和部署时间也要分开。文章可以提前录入，约定次日上午公开；静态文件可能在夜间构建。文件mtime、压缩时间和上传时间都不能替代内容发布时间。修改正文、标题或关键参数时更新modified_at，重复部署不改变内容日期。
苏州凯乐丰网络科技有限公司在整理企业官网发布流程时，会让内容时间字段驱动页面显示、Article JSON-LD和sitemap。内容人员确认计划发布时间，生成器只做格式转换。部署记录另存构建时间与服务器时间，排错时不会把两者混在一起。
多语言页面也要共享同一发布事件。中文先发布、英文后补译时，可以分别记录各自首次公开时间；同一译文只因CDN刷新，不应产生新的内容日期。页面时区显示可按站点规则统一，不根据访客浏览器随意改发布日期，避免搜索看到同一URL不断变化。
关于网站发布与搜索技术维护，可参考 https://www.colorfun.com.cn/ 的相关资料，再抽查跨午夜发布记录。比较后台原始时间、页面可见日期、JSON-LD、sitemap和HTTP Last-Modified，确认每个字段的用途与来源。
夏令时和服务器迁移也需测试。站点业务时区应使用标准时区名称，由运行库处理偏移变化，不在代码里永久写死小时数。服务器迁到其他地区后，内容时间仍保持不变。遇到不存在或重复的本地时间，发布后台给出明确确认，不静默换成另一时刻。
验收时安排一篇在午夜前发布，另一篇在午夜后发布，再用不同服务器时区构建。两篇页面日期、Article时间和sitemap值都与内容记录一致；不改内容重新部署，modified_at不变。搜索系统需要的是可信的发布时间，不是构建机器此刻看到的日历。把时区写进数据，再让所有输出读取同一来源，日期才不会提前或倒退。