Event Time and Record Entry Time

1. Name the two time questions before recording anything

One record can answer two different questions. “When did this happen?” is about the event: a stock-room key was handed over, a site was checked, a customer called, or an item was received. “When was this written into the system?” is about the entry. These moments can match, but they are not interchangeable.

Suggested practice: define event time as the best-supported time at which the business occurrence happened. Define recorded-at as the system-generated or otherwise traceable time at which the record was entered. Do not allow a label such as “date” to carry both meanings. A reviewer should be able to see whether a late entry is late because the work happened later, or because it was recorded later.

For important record types, add a stable record reference, event-time value, precision, timezone context where relevant, event-time basis, recorded-at value, late-entry reason where relevant, and named owner for unresolved timing. This is a field dictionary for chronology, not a correction-history log or a recurring-task design.

2. Match precision to the evidence you actually have

A complete timestamp can look reassuring while creating a false sequence. If a colleague knows only that a handover happened on Tuesday, recording Tuesday is more accurate than attaching 09:00, 12:00 or the time the form was completed. If the person knows it happened during an afternoon round but cannot support a minute, preserve that limited precision in a note or defined choice.

Suggested practice: allow at least three precision states: date and time known; date known but time unknown; and event time unknown. If your work needs a broader statement such as “morning” or “after delivery,” keep it as described evidence, not as a fabricated clock value. State what supports the event time: an observed handover, a normal business source, or a later recollection. The basis helps a reviewer understand the limit of the record.

Do not substitute the recorded-at time for a missing event time. That changes the claim from “entered at this time” to “happened at this time.” Likewise, do not use a default midnight merely because a system requires a timestamp. If the current tool cannot hold a date-only event honestly, use a clear precision field or controlled note while the workflow rule is being tested.

3. Keep recorded-at traceable without making it do the event’s job

Recorded-at is useful evidence of when information became available to the team. It can explain why a morning review did not include an event that was entered later, and it can help an owner identify records that need a timing check. It does not prove the event itself occurred then.

Suggested practice: make recorded-at automatic where the chosen system can provide it, or record it consistently in the current worksheet. Avoid asking staff to guess or backdate recorded-at. If a record was first written elsewhere and copied in later, describe the copy or entry context briefly rather than presenting the later system time as the original event time.

A late entry need not be treated as wrongdoing. Staff may have been offline, busy with the work, waiting for a source, or consolidating a paper note. Use a short reason that supports action, such as “entered after return from site” or “date confirmed from handover note.” Avoid vague wording such as “updated” when the question is specifically why the system record followed the event.

4. Record timezone context and uncertainty honestly

A local date and time is not complete context when people, sites or records cross locations. A browser control for entering a local date and time does not itself provide a timezone. That product fact matters only when your process relies on the exact local context; it does not mean every SME record needs a timezone field.

Suggested practice: decide which record types can cross a timezone boundary or be reviewed from another location. For those types, capture an agreed timezone label or location context alongside a known local event time. For ordinary local work, document the normal operating timezone once in the workflow rule and escalate exceptions rather than adding unnecessary fields to every record.

When the timezone is unknown, say so. Do not infer it from the person entering the record, the device clock, or a later meeting time. Treat “time known, timezone unknown” differently from “time unknown.” Those are separate uncertainties and can lead to different next checks. Source note: MDN, “input type=datetime-local HTML attribute value,” explains that a local date-and-time input has no timezone-setting control. The two-time worksheet in this guide is original suggested practice.

5. Review late entries without rewriting the sequence

A daily view should answer its question deliberately. A review of work completed yesterday should sort primarily by event date, while keeping recorded-at visible so a supervisor can spot entries made after the review cutoff. A review of newly available information may sort by recorded-at instead. One sort order cannot answer both questions safely.

Suggested practice: set a simple late-entry review rule. For example, records entered after the routine review but claiming an earlier event date go to a small exception list. The reviewer checks that the event precision, evidence basis and late-entry reason are present. If the time is not supportable, reduce precision or mark it unknown; do not force the event into a neat sequence.

This is different from correcting an already recorded value. If an event date needs amendment, preserve the correction context under your team’s correction rule. The present guide concerns the first entry’s two time meanings. For a separate approach to edits that affect active work, see the correction-history guide.

6. Fictional example / 虚构示例: next-morning key handover entry

Fictional example: In a fictional stock room, a supervisor hands a spare key to a colleague late on Tuesday. The colleague is occupied with closing tasks and records the handover the next morning. The worksheet records the stable handover reference; event date Tuesday; event time unknown; event-time basis “colleague’s handover note”; normal local timezone context; recorded-at Wednesday morning; and late-entry reason “entered after closing tasks.” It does not claim the key was handed over on Wednesday morning simply because that is when the record was typed.

If the colleague can support that the handover happened at 17:20 local time, the event may instead show that time and its timezone context. If the only supported fact is Tuesday, the worksheet stays date-only. Suggested practice: let the owner review any open task that depends on the key and make the next action visible. This fictional example is teaching material, not a customer case, policy or performance claim.

7. Desk-check the rule before implementation

Test the dictionary with a small set of ordinary records: one entered immediately, one entered later with a known event time, one with only an event date, and one with an unknown event time. Ask two reviewers to reconstruct what happened and what became known when. If they reach different conclusions, improve the field names, allowed precision or evidence prompts before changing dashboards.

Suggested practice: write the report rule beside each view: “sort by event date,” “sort by recorded-at,” or “show both.” Give unresolved event timing one owner and one next action. Do not make an unknown event time disappear from a report merely because it is difficult to sort; place it in a visible exception group.

When the operating rule is clear, BossFlow can review timestamp configuration, access, integration and implementation scope. SME Systems provides education; implementation and quotation discussion remain with BossFlow.

Practical Checklist

• Choose one record type where late entry can distort daily sequence.
• Define event time and recorded-at as two separate fields or worksheet columns.
• Add an event-time precision choice: date and time known, date known only, or unknown.
• Record the evidence basis for event time when it is entered after the event.
• Add timezone or location context only where the workflow needs it.
• Use a concise late-entry reason when recorded-at follows the event materially.
• Set each report’s sort rule explicitly: event time, recorded-at, or both.
• Test four sample records with two reviewers before changing forms, dashboards or automation.