The task and original case
Convert an ambiguous clock time into two explicit possible instants. America/Chicago at 01:30 on November 1, 2026 occurs twice in this exercise. A local string alone cannot tell you which occurrence the writer intended, so the useful output preserves the uncertainty.
| Case element | Value or requirement |
|---|---|
| Inputs | America/Chicago 2026-11-01 at 01:30, with the two possible fold settings. |
| Build | A time-zone conversion example with an explicit ambiguity choice. |
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
Use a timezone-aware datetime with ZoneInfo("America/Chicago"). Create one version with fold=0 and another with fold=1, then convert each to UTC. Python's zoneinfo documentation describes fold for offset transitions. Retain the local string, zone name, fold setting, UTC offset and converted instant in the output.
Do not choose a fold merely to make a schedule look convenient. Your exercise may show both candidates, while a real record would need an offset, source convention or confirmation. Distinguish this repeated local time from a nonexistent local time at another transition; a general import utility needs a declared validation policy for both conditions.
Sources[1]
Check the worked result
The first occurrence converts to 06:30 UTC and the second to 07:30 UTC. They are one hour apart despite sharing the local representation 01:30. The artifact should display both candidates and the absent evidence needed to choose between them.
A subtraction between the converted UTC instants makes the difference explicit. Simply sorting the identical local strings or retaining only “November 1” loses the information this project is intended to expose.
Make the failure visible
Remove the zone name and notice that fold alone is insufficient: the applicable transition rules are unknown. Test a nearby unambiguous time such as 03:30 and confirm it does not produce two different candidates under the same zone. Also avoid using a fixed abbreviation as a substitute for a named zone when the exercise depends on seasonal offsets.
Revise it and ask someone to reproduce it
Ask a peer to supply an explicit offset for the 01:30 record. Select the matching candidate and keep the reason beside the resolved value. Then return to the unresolved version and confirm it still displays both possibilities. Record the runtime's timezone-data source or version when making the demonstration reproducible.
- Both 06:30UTC and 07:30UTC candidates are visible.
- The record retains zone, offset and ambiguity choice.
- An unresolved local string is not silently assigned one instant.
Describe the work accurately
After completing your own version, you could adapt this project bullet: “Demonstrated an ambiguous local-time conversion with explicit fold choices, UTC candidates and a documented resolution requirement.”
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.