# `Tempo.ZoneOffsetMismatchError`
[🔗](https://github.com/kipcole9/tempo/blob/v0.20.0/lib/tempo/exception/zone_offset_mismatch_error.ex#L1)

Exception raised (or returned) when an IXDTF value's explicit numeric
offset disagrees with its IANA time zone at the value's wall instant.

An IXDTF string may carry both a numeric offset and a zone identifier,
for example `2022-11-20T10:37:00+05:00[Europe/Paris]`. Paris is
`+01:00` in November, so the stated `+05:00` is inconsistent. RFC 9557
§4.2 identifies this as a condition a consumer MAY treat as an error;
Tempo surfaces it through `Tempo.validate_zone_offset/1` and the
`strict: true` parse option rather than silently letting the zone win.

# `t`

```elixir
@type t() :: %Tempo.ZoneOffsetMismatchError{
  __exception__: term(),
  stated_offset: integer() | nil,
  wall_time: String.t() | nil,
  zone_id: String.t() | nil,
  zone_offsets: [integer()]
}
```

# `format_offset`

```elixir
@spec format_offset(integer()) :: String.t()
```

Format an offset in seconds as a signed `±HH:MM` string.

### Examples

    iex> Tempo.ZoneOffsetMismatchError.format_offset(3600)
    "+01:00"

    iex> Tempo.ZoneOffsetMismatchError.format_offset(-18000)
    "-05:00"

---

*Consult [api-reference.md](api-reference.md) for complete listing*