# Changelog

## [v0.3.0] — 2026-10-31

### Breaking changes

* The `:calendar` option of `Localize.Inputs.Date.Parser.parse_date/2` and the `:calendar` attribute of every component take a calendar module, such as `Calendrical.Hebrew`, and default to `Calendar.ISO`. A CLDR calendar type, such as `:hebrew`, is refused by the parser and renders in `Calendar.ISO` in the components, where it used to be resolved to a module.

* One CLDR calendar type can name several calendars — `:gregorian` names both `Calendar.ISO` and `Calendrical.Gregorian` — so resolving it answered in a calendar the caller had not named.

### Changed

* Requires `calendrical ~> 2.0` and `localize ~> 1.4`, and is tested against `localize 1.5`. `Localize.Inputs.Date.Parser.parse_date/2` keeps its `:return_calendar` option, which Calendrical 2.0 does not have.

* A parse error is `Localize.DateParseError`, which Calendrical 2.0 returns, where it was `Calendrical.DateParseError`.

* A Hebrew date's month is its place in the year, as Calendrical 2.0 numbers it: `"2026-05-16"` parses to `~D[5786-08-29 Calendrical.Hebrew]`, where it was `5786-09-29`.

* A week parses in the locale's own weeks, as Localize 1.4 counts them: `"week 20 of 2026"` in `:en` is Sunday `~D[2026-05-10]`, where it was Monday `~D[2026-05-11]`.

### Fixed

* `date_input/1` and `date_range_input/1` format a string value in their calendar again; on Calendrical 2.0 they showed it as typed.

* `Localize.Inputs.Date.Parser.parse_date/2` returns `{:error, Localize.InvalidValueError{}}` for a value that is neither a string nor `nil`, where it raised `FunctionClauseError`. A form field sent more than once arrives as a list, so a consumer parsing params directly could crash its request path.

## [v0.2.0] — 2026-07-31

### Changed

* Requires `localize ~> 1.0`, `calendrical ~> 1.0` and `localize_inputs_core ~> 0.2`. The previous requirements excluded Localize 1.0.

## [v0.1.2] — 2026-05-17

### Bug Fixes

* `date_range_input/1` no longer 500s when the consumer's form is built without pre-declaring the derived `:<field>_from` / `:<field>_to` atoms (e.g. a standalone playground page or a `Phoenix.HTML.FormData.to_form/2` map with bare keys). 0.1.1's `String.to_existing_atom/1` raised `ArgumentError` in that case; the derivation now prefers `to_existing_atom` and falls back to `to_atom` when the atom hasn't been loaded yet. The `@field` attr is a developer-supplied component attribute bounded by source code, so the atom-table-safety rule (no `to_atom` on untrusted input) doesn't apply.

## [v0.1.1] — 2026-05-17

### Bug Fixes

* `<.date_input>` and `DatePickerLive` no longer raise on a date that can't be converted into the requested calendar. `Date.convert!/2` and `Date.new!/3,4` replaced throughout with tolerant `safe_convert/2` and `safe_build_date/4` helpers that fall back to the input date or today rather than crashing the render path.

* `<.date_range_input>` switched from `String.to_atom/1` to `String.to_existing_atom/1` when deriving the `{field}_from` / `{field}_to` child fields, preventing atom-table pollution from user-supplied field names. Consumers' schemas already define these atoms for form parsing to work, so this is invisible in practice.

## [v0.1.0] — 2026-05-17

Extracted from `localize_inputs` 0.3 alongside `localize_number_inputs` and `localize_inputs_core`. Carries the date form input components — date_input, date_range_input, date_range_picker, and the `DatePickerLive` LiveComponent — plus their parser, validator, and Ecto Changeset bridge. Depends on `calendrical` for multi-calendar (Gregorian, Buddhist, Japanese, Islamic, Persian, Hebrew, ROC, …) parsing.

### Added

* Requires `calendrical ~> 0.5`. Picks up the broader TR35 parser coverage (every `availableFormats` skeleton, quarter / week / day-of-year / weekday-validation date fields, flex day periods, time-zone resolution) and the new calendar-preserving parse return — `Localize.Inputs.Date.Parser.parse_date/2` now returns a `Date` in the calendar named by the `:calendar` option (e.g. `~D[5786-09-29 Calendrical.Hebrew]`).

* Display formatting re-parses string field values under the component's `:calendar`, so inputs like `"令和8年5月17日"` (Japanese imperial) round-trip without falling through to a Gregorian re-interpretation.

* Internal cleanups now that `:calendrical` is a hard dependency — runtime `Code.ensure_loaded?` guards removed, calendar-conversion helper made idempotent.