A newly received file can still have an old modification time
The time written into a file's metadata does not necessarily say when your organisation received it. A transfer can preserve the source modification time while placing the file in a new location today. An intake process that uses the former as evidence of the latter can miss a perfectly valid delivery.
This worked example concerns a fictional supplier document queue. It investigates admission to review, not which document revision should become authoritative. Receiving a file makes it available for the agreed review; it does not approve its contents or supersede an earlier instruction.
Start with a delivery that staff can identify
Supplier document D-71 was last modified on 4 November 2026 at 08:30 UTC. It arrives through the organisation's agreed transfer process on 6 November at 09:05 UTC. In Europe/Belgrade those fixture times are 09:30 on 4 November and 10:05 on 6 November respectively.
The transfer preserves the old modification timestamp. The intake worker last checked the folder at 09:00 UTC on 6 November and selects only files whose modification time is later than that checkpoint. D-71 is present and readable, but its old timestamp fails the selection. No review task appears.
| Evidence | D-71 result |
|---|---|
| File contents | Complete synthetic document bearing D-71 |
| Source modification time | 4 November, 08:30 UTC |
| Completed receiving event | 6 November, 09:05 UTC |
| Worker's previous checkpoint | 6 November, 09:00 UTC |
| Old selection test | Modification time is not later than checkpoint |
| Staff review queue | D-71 absent |
The customer may describe this as a lost file. The evidence shows a narrower failure: the file exists, but the rule for admitting it to the queue measures the wrong event.
Verify which timestamp the transfer preserves
Inspect the actual receiving process and the source of each timestamp. File modification, completion of transfer, admission to a review queue and business approval are separate facts. A field named “date” or “updated” is not enough to establish which one it represents.
Metadata preservation is an ordinary supported behaviour in some copying tools. For example, Python's shutil.copy2 documentation explains that it attempts to preserve file metadata. The exact metadata retained depends on the operation and platform. This reference supports the possibility; the diagnosis still requires inspecting the specific transfer and D-71's actual stored times.
Changing the display time zone would not fix the queue. Both compared values in the fixture are already UTC instants. Presenting them in Belgrade time helps the receiving team understand the sequence, but it does not turn source modification into receipt.
Define admission around a completed receiving event
The team examines the supported intake facility and finds that it can record completion of an accepted transfer with an event identity, a stored-file reference and a receipt instant. Those are the facts needed for admission. The file's original modification timestamp remains useful provenance alongside them.
The selected correction consumes completed receiving events rather than inferring receipt from file metadata. Each admitted event retains its relationship to the stored artifact and resulting review item. An incomplete transfer is not eligible merely because a directory entry exists.
The review requirement is explicit: one new task for a newly admitted receiving event, with its document identity and source time available to the reviewer. Reprocessing that same event must not create another task. This contract does not decide whether a separate later delivery is a new version, an exact duplicate or material to reject; those are business review rules of their own.
Recover the missed intake without rewriting its history
The maintainer reconciles the completed receiving ledger against the review queue. Event I-71 establishes D-71's completed receipt at 09:05 UTC. It has no corresponding queue entry, so the authorised recovery admits I-71 and creates review task T-71.
T-71 now links to the received D-71 file. Its receipt time remains 6 November at 09:05 UTC, while its source modification time remains 4 November at 08:30 UTC. The correction does not touch the source metadata to make the document look newer.
A subsequent worker run encounters I-71 again and recognises the recorded admission; it does not create T-72 for the same event. Staff retrieve D-71 from T-71 and leave it awaiting the named business review. A separate pre-existing task T-70 retains its original document and state.
Check cases that distinguish the two meanings
| Fixture | Expected admission result |
|---|---|
| Newly received D-71 with preserved old modification time | One review task for completed I-71 |
| Newly received D-72 with a recent modification time | One review task for its own completed event |
| I-71 encountered again | Existing T-71 retained; no additional task |
| Copy exists but transfer is incomplete | No completed-intake claim |
| File type outside the approved intake contract | Held or rejected through the defined exception path |
| Unrelated existing T-70 | No reassignment or timestamp change |
Also examine the recovery record. It should explain why I-71 was admitted late and who authorised that correction. Hiding the delay by replacing the original receiving instant would make later investigation less reliable.
Keep the operating handover explicit
The next operator needs the admission rule, the relevant ledger and a reconciliation procedure. A folder listing alone cannot establish that every completed delivery reached review. Conversely, an empty queue does not prove that no file arrived.
Agree who investigates an intake gap, what evidence they preserve and how the business distinguishes newly received material from an approved replacement. The same questions matter during data migration and system integration, where preserved metadata can be valuable without being a reliable arrival signal.
A useful acceptance record keeps the timestamps named, the file identity intact and the receiving outcome visible. It lets the organisation explain both when the document changed at its source and when responsibility for reviewing the delivered copy began.