The direct answer
Keep one explicitly selected aware UTC instant as the identity of a one-off schedule, and derive its local review display through a supported time-zone conversion. In the selected Python profile, equal local datetime objects can conceal different instants because same-zone comparisons ignore fold. A fold value or successful construction does not establish valid civil time, approval or execution.
Decide what the reviewer is actually choosing
An assistant proposes “prepare the internal report at 01:00.” A review screen repeats that label, but the application needs one particular instant. If the clock repeats an hour, choosing the later occurrence can change the instant without changing the visible hour and minute.
The existing approval snapshot guide explains how to preserve significant fields. This worksheet supplies an earlier temporal decision: what those fields must distinguish. It selects one-off work only, with an independently owned aware UTC instant and a derived named-zone display. It implements neither a scheduler nor a civil-time input resolver.
Freeze the selected comparison and conversion profile
The two Python references identify documentation version 3.15.2. The datetime reference says a naive object leaves its UTC/local interpretation to the program. For aware operands sharing the same tzinfo object, equality and ordering ignore tzinfo and fold; intra-zone subtraction also makes no offset adjustment. Local equality therefore is not our instant-identity test.
The same reference describes astimezone() as preserving UTC time while adjusting the local representation. replace(tzinfo=...) attaches a zone without that adjustment. Our proposed adapter uses an already established aware UTC value and an explicit admitted ZoneInfo destination. It excludes naive conversion, system-local defaults, custom tzinfo subclasses, arbitrary parsers and alternate serialization paths.
Before using the worksheet, establish the actual interpreter, adapter and rule data. A documentation release does not identify an installed runtime. The selected application policy requires explicit UTC-to-UTC instant comparison where comparison is needed; it does not rely on comparing a repeated local representation directly with a differently zoned object.
Make the repeated-hour choice visible
The ZoneInfo documentation illustrates America/Los_Angeles on 1 November 2020: 08:00 UTC becomes 01:00 with offset −07:00, and 09:00 UTC becomes 01:00 with offset −08:00. Conversion sets the corresponding fold value. These are documented example facts, not conversions performed for this article.
Our original review worksheet borrows that historical boundary to explain a decision; it schedules no historical or future job. Invent work W-A, “prepare one internal draft,” and two alternative instant labels U-E and U-L. The reviewer intends the later occurrence. A trusted application must already own U-L independently of any model assertion.
| Field | Worksheet value | Why retain it |
|---|---|---|
| Work and proposal | W-A / P-A | Identify this bounded internal draft |
| Selected instant U-L | 2020-11-01 09:00 UTC | Retain the later instant, not just “01:00” |
| Alternative U-E | 2020-11-01 08:00 UTC | Expose a different instant with the same clock label |
| Derived local display | 2020-11-01 01:00, America/Los_Angeles, offset −08:00, fold 1 | Explain the selected occurrence to the reviewer |
| Association revision | R-A | Bind the instant and displayed context together |
| Runtime and rule-data evidence | Not established here | Block actual admission until independently established |
The ordinary positive starts with owned U-L, derives its display through the supported adapter, and presents both together. It never promotes a model’s preferred fold flag into the trusted selection. Every real prerequisite remains unknown in this exercise.
Do not turn fold into a validity certificate
PEP 495 distinguishes a repeated interval, called a fold, from a skipped interval, called a gap. For an ambiguous local time, fold 0 selects the earlier reading and fold 1 the later one. Constructors and replace() can nevertheless produce invalid instances; they do not check civil-time validity.
This plan consequently holds unresolved civil input rather than silently choosing, shifting or repairing it. A successful constructor, an offset-bearing rendering, or an asserted round trip is not this application’s validation certificate. A separately reviewed resolver would be needed to accept arbitrary civil input; none is supplied here.
The proposed positive avoids that missing resolver by starting from an independently selected instant. That is a deliberately narrower product decision, suitable when the application can offer an explicit instant-selection workflow. It does not answer recurring “every day at this local hour” scheduling.
Review eight inert acceptance cards
All cards are PROPOSED_UNRUN. Labels designate worksheet alternatives, not Python objects or observed runtime results.
| Card | Condition | Proposed disposition |
|---|---|---|
| 1. Ordinary positive | Owned U-L, established adapter/rules, matching derived display and W-A. | Conditionally ready for review of this association; no execution claim. |
| 2. Clock label only | P-A contains only the repeated “01:00” and zone. | Hold for an explicit supported instant choice. |
| 3. Equal local fields | Earlier and later alternatives have identical local fields and the same tzinfo object. | Do not use local equality or subtraction to collapse their instant identities. |
| 4. Zone attachment | An unverified adapter merely attaches a zone to naive input. | No supported instant-selection evidence; hold. |
| 5. Missing civil time | A gap label arrives with fold 1. | Do not infer validity or silently repair it. |
| 6. Unknown rules | Effective runtime or time-zone data cannot be established. | Positive prerequisite absent; do not admit the association. |
| 7. Recurrence request | The instruction becomes “every day at 01:00.” | Outside this one-off contract; require separate requirements. |
| 8. Changed association | U-L, display context or W-A changes after review. | Present the changed association again and independently check current work rights. |
Keep rule provenance and execution evidence separate
ZoneInfo obtains data from system time-zone files or the first-party tzdata package; the module does not bundle that data itself. A familiar zone key does not establish our deployment’s effective rule version. Our application policy requires supported evidence for that context before displaying an association as ready.
Also require trusted work ownership, bounded processing, current permission and a supported review-to-scheduler handoff. Stable time representation establishes none of them. This guide makes no clock-accuracy, delivery, exactly-once, leap-second, completion or future rule-stability promise.
For these proposed cases, no datetime or ZoneInfo object was constructed, parsed, converted or compared; no timer, scheduler, calendar, model or API experiment occurred. Boundary remains prelaunch with planned request-path checks. Its separate mock policy evidence does not implement or validate this temporal controller.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.