DateTime timezone handling has no DST-aware offset resolution (name→IANA-id mapping only)

[jscott3201]

Problem

haystack-core/src/kinds/tz.rs only maps a Haystack city-style timezone name to an IANA zone identifier string; it does not resolve UTC offsets at all:

pub fn tz_for(name: &str) -> Option<&'static str> {
    // City name lookup (most common case)
    if let Some(iana) = TZ_MAP.get(name) {
        return Some(iana.as_str());
    }
    ...
}

haystack-core/src/kinds/datetime.rs's HDateTime stores a chrono::DateTime<FixedOffset> plus the tz name string as parsed from the wire format — the offset is whatever was embedded in the source Zinc/JSON text, never recomputed from (tz_name, instant):

pub struct HDateTime {
    pub dt: DateTime<FixedOffset>,
    pub tz_name: String,
}

haystack-core/Cargo.toml depends on plain chrono (chrono = { version = "0.4", features = ["serde"] }) with no chrono-tz, so there is no DST rule database anywhere in the crate — tz_for() cannot turn ("New_York", 2024-07-01) into -04:00 vs ("New_York", 2024-01-01) into -05:00; it only ever returns the static string "America/New_York".

Impact

Any code path that needs to compute or re-derive an offset for a named zone (e.g. constructing a DateTime from a naive local time + tz name, or validating that an ingested offset matches the tz name for its date) must re-resolve via an external DST-aware zone database (e.g. chrono-tz) in the application layer. hisRead window queries and any date-arithmetic that crosses a DST boundary for a named-TZ series are error-prone unless the ingest layer independently guarantees the embedded offset is already DST-correct for every point in the series.

Proposed direction

Add an optional chrono-tz cargo feature that provides a real (tz_name, NaiveDateTime) -> FixedOffset resolver (backed by tz_for()'s existing city→IANA mapping to look up the chrono_tz::Tz), so callers who need DST-correct offset computation don't have to reimplement the city-name mapping against a separate zone database.

References

Project Haystack DateTime (Zinc 2024-01-01T08:12:05-05:00 New_York); IANA Time Zone Database.

[jscott3201]

Fixed by #31, merged to dev as 624c85e.

resolve_local_offset(name, NaiveDateTime) behind a default-off chrono-tz feature, routed through the existing tz_for() city→IANA mapping so callers do not reimplement it.

It returns Option<LocalResult<FixedOffset>> rather than Option<FixedOffset>, which is the part worth knowing: a naive local time can be non-existent (the skipped hour at spring-forward) or ambiguous (the repeated hour at fall-back), and collapsing those into a single offset would have reintroduced exactly the silent-coercion shape #15 and #16 were about. Both edge cases are tested against real transitions.

This is the first cargo feature in haystack-core, so CI gained feature-on clippy and test steps — otherwise the gated code would never have compiled in CI at all. chrono-tz 0.10.4, MIT OR Apache-2.0, passes cargo deny check.