A staff note should not make an old assessment look newly accepted

Queue age is useful only when its starting event matches the decision the team is trying to make. A record can have an accurate last-modified time and still use that time incorrectly to decide which customer has been waiting longer.

This fictional example concerns an assessment desk serving a Singapore customer operation. The owner has explicitly chosen to order accepted, still-open assessments by the time each entered that assessment process. The measure is an internal queue rule, not a statutory response period or a promise about staff productivity.

Define what starts the waiting clock

Assessment R-91 was accepted on 4 November 2026 at 09:00 in Singapore. On 6 November at 08:50, a coordinator adds an internal note identifying the customer contact who will answer a question. The note does not withdraw the assessment, create a new one or change its accepted scope.

At 09:00 on 6 November, the queue displays R-91 as ten minutes old. Another case, R-92, was genuinely accepted on 5 November at 16:00 and appears as seventeen hours old. The desk therefore sees R-92 ahead of R-91 under its oldest-first rule.

Both records remain open and eligible for this queue. The issue is not a priority exception chosen by the manager. The display contradicts the owner's stated acceptance-age rule.

Compare the two timestamps without declaring either one wrong

Inspection finds that R-91's acceptance event is still present. Its accepted_at value identifies the original admission to assessment. Its updated_at value correctly identifies the later note change. The queue calculates age from updated_at.

The data describes two different events. Rewriting the note timestamp would damage a true part of the history. The correction belongs in the queue calculation and its stated meaning.

For the dated exercise, the relevant instants are:

The comparison uses identified instants, with the local display provided for the people reviewing the work. A plain clock label without its date and zone would not be sufficient evidence for this calculation. Python's datetime documentation explains the distinction between values that identify an instant with zone information and values whose clock context remains unspecified.

Restore the owner's queue rule

The corrected queue uses the explicit acceptance event for an accepted assessment. At the stated review instant, R-91 has been waiting for 48 elapsed hours and R-92 for 17 hours. R-91 therefore appears first under the agreed oldest-first ordering.

The note remains recorded at 08:50 on 6 November, and the ordinary record view still shows it as the latest modification. The interface labels the queue value “Time since assessment accepted” so readers do not confuse it with time since any staff activity.

The owner has not asked for working-hours subtraction, paused-time accounting or an average response measure. The implementation should not introduce those rules simply because they are common in another product. If such a measure is later wanted, its events and treatment require a separate definition.

An external promised response date also remains unchanged. A corrected age display is not authority to extend a commitment or decide that a particular case may be left unattended.

Let a new assessment start only through its actual process

A new assessment can legitimately have a later start, but an ordinary edit must not manufacture it. In this fictional arrangement, an authorised person must create a new assessment identity and record its explicit acceptance event.

A control case, R-93, is accepted at 08:55 on 6 November after its own admission review. At 09:00 it is five minutes old and appears behind both R-91 and R-92. It does not inherit another case's age merely because the customer or equipment reference is similar.

If work is being reconsidered under R-91 rather than opened as a new assessment, the original clock remains. The owner must decide what a genuinely new assessment means; a developer should not reset the start whenever a subject line, contact or attachment changes.

The history links any related assessments without overwriting the earlier acceptance evidence. Staff can then explain the difference between an updated case and a newly admitted one.

Test the task that uses the number

The private exercise checks the ordinary operator's sorted queue and the underlying record. It confirms the following results:

• Adding another internal note to R-91 changes its modification history but leaves its acceptance age and place relative to R-92 intact.
• R-92 retains its own 17-hour age at the fixed review instant.
• Newly accepted R-93 remains a separate five-minute case.
• An enquiry not yet accepted for assessment is shown in its appropriate intake state, without a fabricated acceptance timestamp.
• A future or malformed acceptance value is held for data review rather than displayed as a negative age or silently replaced with the current time.
• R-91's external promised date and the content of its contact note remain unchanged.

These are results for the stated fictional rule and fixed fixture. They do not establish that every queue should prioritise age or that elapsed waiting time measures how long someone has actively worked on a case.

Keep the event meaning with the handover

Document which action creates accepted_at, who may correct a mistaken event and how that correction is recorded. The queue maintainer also needs to know why updated_at remains useful elsewhere and must not simply be removed.

A future change to the assessment process should revisit the metric definition before changing its label or calculation. Use operations tools for the underlying case responsibilities and reporting dashboards when the team needs a view that preserves those meanings across systems.