Consistent DST disambiguation policy across chrono-tz, time-tz, and jiff

Answer

Yes. Centralize the rule in one internal module and adapt it to each crate's API. Do not rely on crate defaults.

Confirmed facts

• chrono-tz: Tz::from_local returns LocalResult::Single, Ambiguous or Nonexistent. No implicit rule is applied; the caller must resolve.
• jiff: jiff::Zoned::new requires an explicit disambiguation strategy and offset preference at construction. There is no implicit system-default mode.
• time: the time crate with tz support applies an implicit default for ambiguous and gap times, commonly earlier offset for ambiguous times and forward shift for gaps. The default is crate-defined and can drift between versions.
• No crate documents a "system default" mode that mirrors host OS behavior such as glibc tm_isdst=-1.
• Embedded tzdata is fixed at compile time unless the crate is used with a runtime tzdb loader.

Likely explanation

The three crates were designed with different safety models: chrono-tz is explicit, jiff is explicit, time is opinionated. A uniform policy must be enforced by you, not by the crates.

Pattern for a consistent policy

1. Define a single policy type

enum DisambiguationPolicy {
    Reject,               // error on ambiguous or nonexistent
    PreferEarlier,        // first occurrence in fall-back
    PreferLater,          // second occurrence in fall-back
    ShiftForward,         // map gap to first valid instant after gap
}

Pick one policy for the whole service and document it. Reject is safest for storage; PreferEarlier/PreferLater is only acceptable for user-facing display with explicit UI.

2. Adapter per crate

chrono-tz

fn from_local_policy(tz: &chrono_tz::Tz, dt: NaiveLocal) -> Result<DateTime<Tz>, Error>

Match on LocalResult and apply the policy: choose the first/second variant for Ambiguous, shift or error for Nonexistent.

time

time does not expose a disambiguation flag on OffsetDateTime::to_offset. Wrap the conversion and, when the wall time is ambiguous or in a gap, compute the two candidate instants via the tzdb and select per policy instead of accepting the crate's implicit earlier/forward default.

jiff

Zoned::new_with_offset(...)? with disambiguation = policy_to_jiff(policy)

Map your enum to jiff's disambiguation and offset preference values at construction time.

3. Verify consistency

• Test with a known ambiguous wall time, e.g. 2025-11-02 01:30 America/New_York, and assert all three adapters return the same instant for the chosen policy.
• Log the tzdata version reported by each crate at startup and compare to the system zoneinfo version.

Keeping tzdata current without a full rebuild

Embedded tzdata will not see OS updates until you rebuild. Options depend on which crates you can change:

• Use a runtime tzdb source. Crates like time and jiff can be built against a tzdb that is loaded from the filesystem at startup, e.g. /usr/share/zoneinfo. Load once at boot and reuse.
• Centralize on a single runtime tzdb crate and derive the zone objects for the other crates from it where possible. For chrono-tz, which embeds data at compile time, you either accept rebuilds or replace chrono-tz usage with a runtime-capable library for new code.
• On deployment, ship a tzdata file with the binary and reload it on process start via an environment variable or config path. This avoids a Rust rebuild but still requires a redeploy of the data file.

Assumption: you are on recent versions of chrono-tz, time 0.3+, and jiff 0.2+. API names for disambiguation differ slightly between minor versions.

One missing diagnostic detail that changes the recommendation: which exact crate versions are locked in Cargo.lock for chrono-tz, time, and jiff. The mapping of policy variants to jiff's disambiguation enum and time's tzdb loader is version-specific.