GrDatePicker

presets draws a row of shortcuts in the footer: “Today”, “Tomorrow”, “Monday”. A date can be set with a function — “today” is computed at the moment of showing rather than at the moment the prop is declared.

A shortcut bypasses the grid, so it checks the prohibitions itself: a date outside min/max or from disabledDates arrives switched off — exactly like its cell in the grid. A button that does nothing deceives.

A footer of your own is the footer slot; it replaces the row as a whole and receives select, canSelect and close.

A date without a time is assembled as local midnight: the user chooses a day in their own calendar rather than a point on the world line. Whoever needs precisely a moment serialises it with an adapter of their own; the package will not substitute UTC silently, because “12 August” in two time zones is two different moments and one and the same day.

mode is passed into the calendar as it is, and the field shows the selection in the ordinary date format:

<GrDatePicker v-model="reportPeriod" mode="quarter" />

A week puts its beginning into the model, a quarter and a month the first day, and a year the first of January. The shape of the value does not depend on the mode: there is still one date in the field, and valueAdapter works as it worked.

The details of the modes — ./GrCalendar.md; there too is why a week is drawn as a grid of days rather than as a grid of periods, and why the week number is not shown.

multiple collects an arbitrary set: a schedule of lessons, exception dates in a plan, booked days. The model becomes an array.

<GrDatePicker v-model="lessons" multiple />

The difference from GrDateRangePicker is one of essence rather than of convenience: there there is a continuous segment with two edges and rules about its length, here a set where adjacency means nothing.

A click on a selected date removes it. A set is a toggle rather than an accumulator: otherwise there would be nothing to remove a date taken by mistake with.

The panel does not close after a choice. A set is collected, while a single date is chosen once — and closing after the first click would turn a set of ten dates into ten openings of the panel.

The order is always ascending, wherever the clicks landed. The model has to be comparable: a rearrangement of the elements must not read as a change — otherwise “there are unsaved edits” fires out of nowhere.

Typing in this mode is switched off, even with editable. A string describing N dates requires parsing of its own: how many of them have been collected does not follow from the string, and an incomplete entry cannot be told from a short set. A range and a date with a time describe exactly two values and are therefore typeable (GrDateRangePicker, GrDateTimePicker); an arbitrary set is not.

The first three dates and the remainder as a number (“and 2 more”) are visible in the field: without a ceiling the label overflows already at the fifth. A hidden field per date goes into the form — with one name, the way FormData.getAll reads it.

min, max and disabledDates apply to every date separately, by the same rules as with a single choice.

A choice in the calendar is applied at once, and the loss of focus from the field commits what was typed by hand. Otherwise a date that had been typed but not confirmed would disappear on moving to the next field — while the user believes they entered it.

With editable the value is output in digits (08/12/2026) rather than as Aug 12, 2026. Otherwise editing a number right in the field would leave the parser two groups of digits instead of three: what was typed would roll back silently, although the user broke nothing.

A format of your own overrides that rule — then the readability of what is typed is the consumer’s responsibility. Without editable the display stays as it was.

A forbidden date is not accepted as text either. disabledDates, min and max apply equally to a click and to Enter; a field bypassing the restrictions of the panel would mean there are no restrictions.