The task and original case
Audit whether a delivery met its deadline using instants rather than displayed calendar dates. This is a small operations project with a clear answer and an important limitation: the timestamp's zone and the deadline's rule must be known before a date comparison means anything.
| Case element | Value or requirement |
|---|---|
| Inputs | Due 2026-10-02T 00:00Z; delivered 2026-10-01T 23:30Z. A display layer uses local dates. |
| Build | A timestamp audit showing original values, zone assumptions and elapsed minutes. |
This is an original invented exercise. It is independent practice, with no employer assessment or open-vacancy claim. Download the inputs, attempt your own result, then open the separate answer key.
Data and worked inputs
Build a result another person can follow
Retain the original due and delivered strings. Both supplied values include Z, identifying UTC: due October 2 at 00:00 and delivered October 1 at 23:30. Parse them as timezone-aware values and calculate due minus delivered in minutes. Only then make a local display column.
Python's zoneinfo supports named IANA zones. Use it for a declared display zone such as America/Chicago while keeping UTC as the comparison basis. Store the original string, parsed UTC instant, display zone, local representation and elapsed-minute calculation. Do not infer a zone from a user's address or convert a date-only requirement into a time of day.
Sources[1]
Check the worked result
The delivery is thirty minutes before the deadline. In Chicago, these instants display on the same local date during this exercise; changing the display zone does not change their separation. Your result is “30 minutes early under the stated UTC deadline,” not a conclusion based on which date string looks earlier.
Choose and record a boundary rule. If delivery exactly at the deadline counts as on time, use delivered ≤ due. A different policy would need an explicit comparison rule; the software cannot decide the business requirement for you.
Make the failure visible
Remove Z from the delivered value. Now the input lacks a zone and should be rejected or held for clarification. Also test a delivery thirty minutes after the deadline and an exact-boundary delivery. Avoid comparing only the first ten characters of ISO strings: local dates can differ while instants are ordered correctly, or match while the deadline has been missed.
Revise it and ask someone to reproduce it
Re-render the same two instants in UTC and America/Chicago, then ask a peer to verify that both versions preserve the thirty-minute result. In a second revision, add an unknown-zone record and show the exception beside the valid result. Save the chosen equality rule so a future reviewer can reproduce your classification.
- Raw timestamp strings and zone assumptions are preserved.
- Display-zone changes leave elapsed minutes unchanged.
- Missing-zone and exact-boundary inputs have declared outcomes.
Describe the work accurately
After completing your own version, you could adapt this project bullet: “Audited invented delivery timestamps with aware UTC comparisons, explicit display zones and a documented deadline-boundary rule.”
Use Projects or Independent practice as the heading. Keep the input files, result and revision together. Describe only your own completed work; the invented numbers are model outputs, not employer results or measured business impact.