config: resolve the legacy timezone names IB states its times in (ibx#335)

[userFRM]

Summary

• parse_ib_expiry resolves the timezone straight against the system database. US/Eastern and its siblings are backward-compatibility links, and Debian and Ubuntu ship those in a separate tzdata-legacy package that is not installed by default.

$ dpkg -c tzdata.deb        | grep -c 'zoneinfo/US/'
0
$ dpkg -c tzdata-legacy.deb | grep 'US/Eastern'
./usr/share/zoneinfo/US/Eastern -> ../America/New_York

• That is IB's own spelling — what the gateway sends as a contract's time_zone_id, and the example the warning a few lines above suggests when a time arrives without a zone.

Closes #335.

Why it is silent

The parse error never reaches the caller. attrs() catches it and drops the field:

Err(e) => {
    log::warn!("dropping good_till_date: {}", e);
    (0, 0)
}

So on any host without the legacy package, a GTD order whose expiry is stated the way IB states it goes out with no expiry. It does not expire when it was meant to — it rests, and the only trace is a line in the log.

Change

The names are fixed aliases: US/Eastern is America/New_York and always has been. Resolving them before the lookup makes the parse work wherever the primary names exist, which is everywhere — better than requiring a non-default package at deploy time to accept the vendor's own timezone.

This is what the two failing tests were

config::expiry_tests::named_zone_converts_with_dst and instant_round_trips_to_wire have been failing on any host without tzdata-legacy, for exactly this reason.

Test plan

• cargo test --offline --lib — 806 passed, 0 failed. This branch is what makes the two config::expiry_tests cases pass; they fail on the base commit for want of the legacy timezone files.
• cargo check --offline --features python — clean.

🤖 Generated with Claude Code

[userFRM]

Extended the test to cover all seven mappings rather than five.

US/Alaska and US/Hawaii were mapped but not asserted, which left a real hole: pointing US/Alaska at America/Adak instead of America/Anchorage is a one-hour error and the test passed anyway. Both pairs are in the loop now, and that mutation fails.

The date in the test does work here — June separates US/Arizona from the Mountain zones, so a wrong target there is caught rather than being offset-equivalent.

Worth noting for anyone reading the diff: this guard is environment-dependent by nature. On a host that has tzdata-legacy installed, reverting the fix passes everything, because the legacy names resolve directly. The tests only bite on a stock image — which is what a CI container is, and where the bug bites too.

[userFRM]

Two corrections from the second review, and the first one is the interesting one.

The test could not tell a correct target from a wrong one. It compared a single summer instant, so US/Alaska → Pacific/Pitcairn and US/Arizona → America/Los_Angeles both passed — offset-equivalent in June, an hour apart in December. It now asserts the mapping directly, and checks conversions in both seasons. Three mutations fail on that, including US/Eastern → America/Detroit, which is offset-equivalent all year and no instant comparison could ever have caught.

The mapping no longer overrides the host. It rewrote the name before ever asking the system, so a host that does carry the legacy names — or one with a deliberately customised database — had its own answer replaced. Proven with a divergent TZDIR: the base honoured the custom zone and this change forced the canonical one. It now asks for the name as given first and falls back to the mapping only when that fails, which is the actual deployment problem being solved and also follows any future retargeting in tzdata.

Independent confirmation worth recording: every pair was checked against /usr/share/zoneinfo/tzdata.zi on this host with line numbers, and the compiled TZif files are byte-identical. And the diagnosis was verified from the other direction — supplying the base a zic-compiled database containing US/Eastern makes the two failing expiry tests pass, which proves the missing legacy files are the cause rather than something else about the branch.