AI-Written Time Reports: Two Clock Hours Can Mean Three Elapsed Hours

An AI-generated report says an overnight job took two hours. Its start and finish times are present, both carry time-zone information, and the subtraction runs without an error. Yet three hours elapsed between those events.

That can happen in Python when a calculation crosses a daylight-saving transition. It is a useful reminder that adding a time zone does not, by itself, define what a duration calculation means.

For an independent creator checking an automation, or a business owner reviewing customer waiting times, the first question is what the figure should measure. Are you comparing local clock readings, applying a business-hours rule or measuring elapsed time between recorded instants? Write that down before asking an assistant for the formula.

A concrete London example

The UK clocks went back on 25 October 2026, as listed in the government’s clock-change timetable. Consider a hypothetical job that started at 00:30 in London that morning and finished at 02:30. Its timestamps have different UTC offsets: the start is 00:30+01:00; the finish is 02:30+00:00.

Those correspond to 23:30 UTC on 24 October and 02:30 UTC on 25 October. The elapsed interval is three hours. Looking only at the local hour and minute fields suggests two.

These are constructed example records, not a report of an actual incident. They make a useful test because the endpoints themselves avoid the repeated local hour. We can examine the subtraction rule without first having to choose between two occurrences of the same clock reading.

Why a time-zone-aware subtraction can surprise you

Python’s datetime documentation specifies that subtraction between aware datetime objects with the same tzinfo attribute ignores that attribute for the calculation. It therefore performs no time-zone adjustment in this case.

For the example, construct both endpoints using the same ZoneInfo('Europe/London') object. Subtracting the start directly from the finish returns a two-hour timedelta. This is documented behaviour, rather than evidence that Python has failed to recognise the time zone.

If the requirement is elapsed time between those instants, convert both aware endpoints with astimezone(timezone.utc) before subtracting them. In the tested example, that produces a three-hour timedelta. Use total_seconds() and divide by 3,600 when the report needs a number of hours.

Do not substitute replace(tzinfo=timezone.utc) for that conversion. Python documents replace as changing the attached time-zone information without adjusting the date and clock fields. Relabelling a London reading as UTC is a different operation from converting the instant it represents.

Turn the example into a review request

You do not need to become a time-library specialist to ask for the relevant evidence. Give the assistant or developer the two explicit example timestamps and the expected three-hour result. Ask them to show the parsed values, their UTC conversions and the final duration.

A useful request is: “Calculate elapsed time between two already identified instants. Show how the implementation handles a change of UTC offset. Do not infer a missing time zone from the computer running the report.” This states a requirement; it does not prove that the returned code meets it.

Then inspect the output from the actual calculation. The difference between two plausible numbers is precisely why a convincing explanation is insufficient. A successful program run tells you that the program executed; the expected result tells you whether it answered your question.

Keep an ordinary-day example as well. On a day when the relevant offset does not change, both approaches can agree. Passing only that test would leave this particular mistake undiscovered. In checking the example for this article, both the transition case and an ordinary London day were run locally.

A repeated clock reading needs more information

Python’s zoneinfo documentation explains the fold attribute for ambiguous local times during an offset transition. It distinguishes the occurrence before the transition from the occurrence after it. Converting from another time zone sets fold appropriately.

That is a separate input problem. If a source gives you only a local date and a clock reading that occurs twice, a duration formula cannot discover which event was intended. Obtain the missing offset, an unambiguous instant or other reliable source information before treating the value as settled.

Do not let an assistant silently choose whichever interpretation makes a row easy to process. Keep uncertain records visible for review. A report with an explicit unresolved case is more useful than a precise-looking duration based on an undocumented guess.

MaryChuks.com’s guide to keeping the time zone with an appointment covers the related scheduling question. Here, the task is different: after events have occurred, establish which instants their records identify and what interval you intend to report.

Agree the business rule before applying the fix

For the hypothetical overnight job, elapsed time is a sensible definition if the owner wants to know how long completion took. A report about staffed support hours might instead exclude periods when the service is closed. Converting to UTC does not create that business-hours policy.

Ask the owner of the metric to approve its meaning in plain language. “Time between receipt and completion, including overnight hours” is more precise than “processing time”. Keep that definition beside the calculation so that a later rewrite does not quietly change what the report measures.

Likewise, do not apply an elapsed-time repair indiscriminately to recurring local appointments or calendar instructions. Those tasks may deliberately preserve a local clock time. The choice of operation should follow the requirement, rather than a blanket rule that every use of dates needs the same arithmetic.

Preserve the evidence behind the duration

Keep the original timestamps alongside the normalised values used for calculation, within the access and retention rules of the workflow. When a duration is challenged, the reviewer should be able to reconstruct which endpoints and interpretation produced it.

Before accepting an AI-written time report, ask for one case across an offset change, one ordinary case and a clear route for ambiguous inputs. Those checks are small enough to discuss with a developer and specific enough to expose this failure. A time zone is part of the data; the meaning of the subtraction is still a decision.

Sources

Primary references, checked 8 November 2026: Python 3.14 datetime operations and conversion; Python zoneinfo and fold; GOV.UK clock-change dates. The job scenario and proposed review routine are illustrative. The stated calculation results were checked in a local Python run.