Changelog

Copy Markdown View Source

[v0.3.0] — 2026-10-31

Breaking changes

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.