Agree Time-Zone Display and Date Boundaries Before System Handover

Set the Review Boundary

Use this suggested workflow practice after the custom system, relevant record type, and intended handover release are already scoped. The purpose is to agree observable evidence for one confirmed timestamp when reviewers view it in two explicitly named time zones. The deliverable is a time-zone display acceptance sheet and one completed fictional test. It is not a broad certification that the product supports every time zone, every browser setting, every report, or every future date.

Begin with the dated scope or release reference, the nonproduction environment, the stable synthetic record reference, and the people who may agree expectations and review evidence. State the narrow question in ordinary language: for this confirmed event, what should each named screen show in Zone A and Zone B, which local date should each date filter use, and how should the export identify its time basis? A useful question can be checked without asking reviewers to infer technical design.

Keep the review outside production. Use synthetic data and permitted test accounts. Do not alter device clocks, authentication settings, payroll dates, legal deadlines, integrations, or live records. If the proposed test needs a configuration change or a newly built view, record that as a separate scope decision rather than silently expanding this handover check.

Name the scoped release
Choose synthetic records
Name both time zones
Confirm review authority

Separate the Five Facts

Write five facts in separate fields before testing. First, the confirmed event reference is the agreed event being viewed, such as a synthetic record reference and its confirmed timestamp text. Second, the displayed zone is the zone label or basis the screen actually makes visible. Third, the displayed local date and time are what the reviewer reads on that screen. Fourth, the filter-date basis says whether the date filter is agreed to use a named local zone, an explicitly labelled alternative, or an unknown basis awaiting decision. Fifth, the export label says how the exported result identifies its date or time basis.

Do not treat a visible date as proof of a particular storage method, conversion rule, user setting, or server location. The review concerns observable output and agreed expectations. If the screen gives no zone label, record that absence rather than guessing. If a developer explains an implementation choice, retain the agreed screen expectation separately from that explanation.

The same distinction prevents a common error near midnight. A single confirmed event can reasonably have one local calendar date in one named zone and another local calendar date in another named zone. The acceptance question is not which date is universally correct. It is whether each agreed view, filter, and export makes its chosen basis understandable and behaves as the reviewers agreed.

Separate reference facts
Label display zones
Record local values
State filter basis
Label export basis

Agree Observable Examples

Choose one synthetic event close enough to a local date boundary that the two named views can expose a meaningful difference. Agree the input reference, input zone, expected display for each zone, expected filter result, and expected export label before observing the product. Ask the developer to confirm what can be tested, but do not copy an undocumented conversion into the expected result. The business reviewer and implementation contact should agree the expected outputs independently before the test is marked ready.

For each screen, name the exact route or view, the record reference, and the action. For a list view, state the filter date and the intended zone basis. For a detail view, state the field or label to inspect. For an export, state the chosen filters, the file or column to inspect, and the expected label. This turns a vague claim that dates look right into a reproducible acceptance example.

GOV.UK guidance on acceptance criteria supports describing outcomes that a reviewer can check and linking evidence to those checks. Apply that principle modestly here: write what a reviewer must be able to observe, not a promise about internals. Keep unresolved assumptions visible so an apparent pass cannot hide an unagreed condition.

Choose boundary event
Agree expected screens
Name filter actions
Identify export evidence
Capture reviewer names

Use the Acceptance Sheet

Create one original row per view or export result. Include: scope and release reference; environment; synthetic record reference; confirmed event reference; input zone; named displayed zone; expected local date and time; actual local date and time; filter date entered; agreed filter-date basis; expected inclusion or exclusion; actual outcome; export label expected; export label observed; reviewer; evidence location; and decision. Avoid blanks that later readers could mistake for a pass. Use not observed, not applicable, or awaiting decision where those states are accurate.

Make evidence proportionate. A screenshot can show a labelled screen and filter result; a retained export can show its label and displayed value; a short test note can identify the account role and observation time. Evidence should help a later reviewer repeat the check without containing real customer or staff data. It need not prove unobservable infrastructure behaviour.

Use one decision for each row: accepted as agreed, exception awaiting decision, retest required, or outside this review. Acceptance covers only the precise view, filter, export, environment, and evidence named in the row. It does not approve an untested report or establish a system-wide time policy.

Complete every field
Preserve safe evidence
State row decision
Mark unknown values
Limit acceptance scope

Decide Exceptions Safely

If displayed output differs from the agreed expectation, stop calling the result a time-zone defect until the facts are clear. Check that the same synthetic record, release, screen, named zone, filter entry, and export settings were used. Then compare the expected and actual values field by field. A missing label, a differing local date, and an unexpected filter inclusion are distinct observations and may require different decisions.

Use a small decision path. If the expectation was never agreed, mark it awaiting decision and assign an owner; do not pass or fail the product against an invented rule. If the output is clear but differs from an agreed expectation, record an exception for the scoped release and decide whether a correction, revised expectation, or explicit exclusion is needed. If the output cannot show its basis, record the observable ambiguity and ask whether the agreed scope requires a label. If a test cannot be performed safely in nonproduction, keep it outside the handover decision and identify what authority or environment is needed.

Do not solve an exception by changing production settings, changing clocks, or relying on memory from a different view. A retest should use a new or clearly reset synthetic record where needed and should retain both the original observation and the retest evidence.

Verify test identity
Classify the gap
Assign decision owner
Keep original evidence
Retest only safely

Fictional Boundary Test

This is fictional. A team reviews synthetic record BF-TZ-014 in a nonproduction release. Its confirmed event reference is 2026-10-19 23:30 in Asia/Kuala_Lumpur. Before testing, the business reviewer and developer agree these expected observable outputs: a Kuala Lumpur detail view labelled Asia/Kuala_Lumpur shows 19 October 2026, 23:30; a Tokyo detail view labelled Asia/Tokyo shows 20 October 2026, 00:30; a Kuala Lumpur date filter for 19 October includes BF-TZ-014; a Tokyo date filter for 20 October includes it; and each export labels the named date basis used.

The reviewer opens the agreed detail views, enters the agreed dates in the respective list filters, and produces each agreed export. The acceptance sheet records the actual text and inclusion result rather than assuming why they appear. Suppose the detail and filter results match, but the Tokyo export contains the expected value without a zone or date-basis label. The completed decision is exception awaiting decision, not full acceptance. The owner must decide whether the existing agreed scope requires a label, whether the export is explicitly excluded, or whether a scoped correction and retest are needed.

The confirmed event has not changed in this example. The review only establishes what was agreed and observed for named outputs. It makes no claim about universal storage, untested devices, future daylight-saving transitions, or other records.

Mark fiction clearly
Use explicit zones
Record expected outcome
Capture actual output
Close with decision

中文指南

设定审阅边界

建议在自定义系统、相关记录类型和交接版本已经定稿后使用本流程。目的，是为同一已确认时间在两个明确命名的时区中的可见结果取得一致证据。交付物是一份时区显示验收表和一项完成的虚构测试；它不是对所有时区、浏览器、报表或未来日期的全面认证。

先准备带日期的范围或版本编号、非生产环境、稳定的合成记录编号，以及可确认预期和审阅证据的人员。用普通语言写明问题：同一确认事件在时区甲与时区乙的指定画面应显示什么；日期筛选依据哪一个本地日期；导出如何说明其时间或日期依据。问题应可观察，不要求审阅者推断技术设计。

测试只在非生产环境进行，使用合成资料和获准测试账号。不要改动设备时钟、认证设置、薪资日期、法定期限、整合或真实记录。若测试需要新配置或新画面，应另记为范围决定，不应悄悄扩大本次交接审阅。

确认交接版本
使用合成记录
明确两个时区
指定审阅权限

分开五项事实

测试前把五项事实分栏记录。第一，已确认事件参考，是正在查看的事件，例如合成记录编号和已确认时间文字。第二，显示时区，是画面实际显示或说明的时区标签或依据。第三，显示本地日期时间，是审阅者从画面读到的内容。第四，筛选日期依据，说明日期筛选是否约定采用某个命名本地时区、清楚标记的其他依据，或仍未知。第五，导出标签，说明导出如何标识其日期或时间依据。

不要把一个可见日期当作某种储存方式、转换规则、用户设置或服务器位置的证明。本审阅针对可观察的输出和已同意的预期。若画面没有时区标签，应记录这个缺失，而非猜测。若开发人员说明实现选择，仍应把已同意的画面预期与该说明分开保存。

接近午夜时，这个区分尤其重要。同一确认事件可以在一个命名时区属于一个日历日期，在另一时区属于另一个日期。验收问题不是哪个日期普遍正确，而是每个约定画面、筛选和导出是否清楚说明其依据，并按约定运作。

分开事件参考
标记显示时区
记录本地数值
说明筛选依据
标记导出依据

约定可见示例

选择一项足够靠近本地日期边界的合成事件，让两个命名视图能够显示有意义的差异。观察系统前，先约定输入参考、输入时区、每个时区的预期显示、预期筛选结果和预期导出标签。可请开发人员确认可测试内容，但不可把未记录的转换方式直接写成预期结果。业务审阅者和实施联系人应在测试准备完成前独立确认输出预期。

每个画面应写明准确路径或视图、记录编号和操作。列表视图须写明筛选日期与拟采用的时区依据；详情视图须写明要检查的字段或标签；导出须写明筛选条件、要检查的文件或栏位，以及预期标签。这样可把日期看起来正确的模糊说法变成可重做的验收示例。

GOV.UK 对验收标准的建议强调描述审阅者可核对的结果，并把证据连结到这些检查。这里可谨慎采用此原则：写下审阅者必须看见什么，而不是承诺系统内部如何运作。未解决假设必须保留可见，避免表面通过掩盖未同意条件。

选择边界事件
约定画面预期
写明筛选操作
指定导出证据
记录审阅人员

使用验收表单

每个视图或导出结果建立一行原始记录。栏目包括：范围与版本编号、环境、合成记录编号、确认事件参考、输入时区、命名显示时区、预期本地日期时间、实际本地日期时间、输入筛选日期、约定筛选日期依据、预期纳入或排除、实际结果、预期导出标签、实际导出标签、审阅者、证据位置和决定。不要留下后来可能被误认为通过的空白；应准确写未观察、不适用或待决定。

证据应与风险相称。截图可显示带标签的画面和筛选结果；保留的导出文件可显示其标签和数值；简短测试记录可说明账号角色和观察时间。证据应协助后续审阅者重做检查，同时不包含真实客户或员工资料；它无需证明看不见的基础设施行为。

每一行使用一个明确决定：按约定接受、例外待决定、需要复测或不属于本次审阅。接受只覆盖该行写明的视图、筛选、导出、环境和证据，不会批准未测试报表，也不会建立全系统时区政策。

填完全部栏目
保存安全证据
写明行级决定
标记未知状态
限制接受范围

安全处理例外

若实际输出与约定预期不同，不要立刻称为时区缺陷。先确认是否使用同一合成记录、版本、画面、命名时区、筛选输入和导出设置，然后逐栏比较预期和实际。缺少标签、当地日期不同、筛选纳入结果意外，是不同观察结果，可能需要不同决定。

可采用简短决定路径。若预期从未同意，标为待决定并指定负责人，不可按臆造规则判定通过或失败。若输出清楚但不同于已同意预期，为该范围版本记录例外，并决定需要修正、修改预期或明确排除。若输出不能说明其依据，记录可见的模糊之处，并询问已同意范围是否要求标签。若无法在非生产环境安全测试，应把它保留在交接决定之外，并写明需要的权限或环境。

不要以改动生产设置、改动时钟或依赖别的视图记忆来处理例外。若需要复测，应在适当时使用新的或清楚重置的合成记录，并同时保留原观察和复测证据。

核对测试身份
分类观察差异
指定决定负责人
保留原始证据
只做安全复测

虚构边界测试

以下为明确虚构的例子。团队在非生产版本审阅合成记录 BF-TZ-014。其确认事件参考为 2026-10-19 23:30，时区为 Asia/Kuala_Lumpur。测试前，业务审阅者和开发人员同意以下可见预期：标记 Asia/Kuala_Lumpur 的详情视图显示 2026 年 10 月 19 日 23:30；标记 Asia/Tokyo 的详情视图显示 2026 年 10 月 20 日 00:30；吉隆坡日期筛选的 10 月 19 日纳入该记录；东京日期筛选的 10 月 20 日纳入该记录；每份导出均标注所使用的命名日期依据。

审阅者打开约定详情视图，在对应列表筛选中输入约定日期，并产生各约定导出。验收表记录实际文字和纳入结果，而非假定其出现原因。假设详情和筛选均符合预期，但东京导出包含预期数值，却没有时区或日期依据标签；完成决定应为例外待决定，而不是完全接受。负责人必须决定既有范围是否要求标签、该导出是否明确排除，或是否需要限定修正和复测。

此例中的确认事件并未改变。审阅只确认命名输出所约定和观察到的内容，不主张通用储存方式、未测试设备、未来夏令时间转换或其他记录的行为。

明确标示虚构
使用明确时区
记录预期结果
保存实际输出
以决定结案

Sources and next step

Discuss your workflow scope with BossFlow · Compare system categories at SME Systems · All articles