Factory.ai

AI Coding Agents

Testing

Time zone testing for agent-generated code

September 27, 2026 - 2 minute read

Time zone testing catches failures that stay invisible when every developer and CI runner uses UTC. Agent-generated code may replace a library, move a conversion, or simplify a schedule while preserving common dates. The defect appears later at a daylight-saving transition, after a time zone database update, or when a user enters an ambiguous local time.

The IANA Time Zone Database records civil-time rules that governments can change. Language libraries consume that data. Python's time zone documentation, for example, explains how the standard library uses system data or the first-party tzdata package and represents ambiguous times with the fold attribute.

Define time zone testing contracts

Separate instants from local civil time. An instant identifies one point on the timeline and can be stored in UTC. A local schedule such as "09:00 every business day in São Paulo" depends on a named region and its changing rules. Replacing that region with a fixed numeric offset loses the rule history.

Write the product decision for nonexistent and repeated local times. During a forward clock change, some wall times never occur. During a backward change, one wall time can map to two instants. The application may reject, shift, or ask the user to disambiguate, but the behavior must be explicit.

Keep the clock injectable. Tests should supply an instant rather than changing the machine clock or waiting for a real transition. Pin or record the time zone database version when reproducibility matters, especially for generated schedules and long-lived fixtures.

Build time zone testing cases

Select representative zones from the application's actual support set. Include UTC, a zone with daylight-saving transitions, a zone without current seasonal changes, and any region central to the product. Avoid assuming every transition moves by one hour.

For each scheduling path, test an ordinary date, the boundary before a transition, the missing or repeated interval, and the next valid execution. Verify both directions: local input to stored instant and stored instant back to the displayed local value.

Test serialization with an explicit offset and, when recurrence matters, the named zone. A timestamp alone can preserve an instant but cannot preserve the rule for future local events. Also run the suite against an updated time zone database in a controlled branch to identify expectations tied to old civil rules.

Review date changes with evidence

The pull request should name the clock source, storage format, supported zone identifiers, ambiguity policy, time zone data source, and exact boundary cases. Screenshots can confirm display, but assertions over instants and local representations provide durable regression evidence.

Factory's Automated QA can exercise web, API, mobile, and CLI behavior and return structured evidence. Pair those flows with deterministic lower-level tests. Factory's Missions planning can keep the date-handling contract and validation commands attached to a longer change.

Stop when the product has no stated policy for ambiguous input. A coding agent should not choose a business rule by copying whichever default a date library happens to use.

Further reading

Ready to build the software of the future?

Start building

Arrow Right Icon