记录时间必须带时区
文中的飞机账号也常被称为Telegram账号、电报账号。同一瞬间在上海、伦敦或纽约可能属于不同日期，所以“昨晚收到”“明天到期”无法供另一时区的人复核。建议写成“2026-09-18 21:35，UTC+08:00”，并把设备所用时区一并记下。若团队成员协助验收，先约定以哪一时区讨论，再把原始显示保留下来，不要只保存换算后的结果。
显示到哪一层就记录到哪一层
官方客户端若显示具体日期与时刻，就完整照录；若只显示日期或相对文字，就如实记录，不自行补成当天23:59，也不把边界日算成完整可用日。3天会员、7天会员和一个月会员都不能仅凭名称换算。需要精确覆盖某个会议或截止时间时，购前信息不够明确就先询问，不能靠猜测填空。
保留原始值和换算值
跨时区沟通最稳妥的写法是两行：第一行写账号界面原样显示与设备时区，第二行写双方约定时区下的换算结果。夏令时、系统自动切换时区或不同设备格式都可能让外观看起来不同；换算有疑问时回到原始记录。不要通过反复改设备时间来“验证”，这只会增加记录混乱。
反馈时只给必要信息
需要客服核对时，提供订单编号、检查时间、时区、使用的官方客户端和脱敏后的到期状态。密码、验证码、完整登录资料、私人聊天与无关通知不属于时间证据。问题描述应写“商品信息是什么、官方客户端显示什么、何时查看”，不要只说“少了一天”或“时间不对”。
跨时区记录步骤
- 开始验收前确认设备时区。
- 记下带年月日和时区的检查时刻。
- 原样抄录官方客户端的到期显示。
- 截取只包含必要区域的画面。
- 如需换算，另写目标时区与结果。
- 将商品信息、原始值和换算值并排比较。
常见问题
- 客户端只显示某一天，没有具体时分怎么办？
- 按它实际显示的精度记录，并为任务留出边界余量；不要自行补出平台没有展示的结束时刻。
- 客服与我不在同一时区，应该发哪个时间？
- 先发原始检查时间和时区，再附双方约定时区的换算值，两者都保留，避免换算结果覆盖原始证据。