Ambiguous local time conversion failure in Data.Time.Calendar

Intended behavior for ambiguous local times

Future Data.Time releases will rely exclusively on the tzdata package for timezone rules. The TimeZone type will expose both possible UTC offsets for an ambiguous LocalTime, and the timeZoneLookup function will return a list of offsets. If no explicit offset is supplied, the library will default to the earlier offset (standard time) to preserve backward compatibility.

Effect of deprecating timezone and zi functions

The deprecated functions supplied a TimeZone value directly; they are removed. Existing conversion code that called timezone or zi will no longer compile. Migration requires replacing those calls with timeZoneLookup from Data.Time.LocalTime.TimeZone.TZ, handling the Maybe (or list) result, and explicitly selecting the desired offset when ambiguity is relevant. Without explicit selection, the earlier offset is used, which may shift timestamps compared to the old behavior.

Steps to adapt existing code

1. Add tzdata to the project dependencies (cabal: build‑depends: tzdata; package.yaml: tzdata).
2. Replace any use of timezone or zi with timeZoneLookup (e.g., let tz = timeZoneLookup Europe/Paris ambiguousLocalTime).
3. When the result is a list of offsets, decide which offset to use; if the code previously assumed a single offset, update the logic to pick the appropriate one.
4. Run a test on a known ambiguous instant (for example, 2023‑10‑29 02:30 in Europe/Paris) to verify that the chosen offset matches expectations.
5. Update any code that performed implicit conversion to UTC, ensuring it now uses the selected offset rather than relying on the deprecated default.

Verification

Run a minimal test that creates a LocalTime on an ambiguous date, calls timeZoneLookup for the relevant IANA zone, and prints both offsets. Confirm that the default conversion uses the earlier offset and that your explicit selection yields the intended UTC time.