Filament Thai Date Picker Laravel Package

Getting Started

phattarachai/filament-thai-date-picker gives Filament form components that render and display dates in Thai/Buddhist Era conventions without you hand-rolling locale switching.

Requirements check first. v4.1.0 requires filament/forms 5.10.1+. If your app is on an older Filament 5, Composer will keep you on 4.0.x — check your lock file before reporting a missing feature:

composer show filament/forms | grep versions
composer require phattarachai/filament-thai-date-picker:^4.1

First use case. Drop the field into an existing Resource form and confirm the round trip:

use Phattarachai\FilamentThaiDatePicker\ThaiDatePicker;

ThaiDatePicker::make('published_on')
    ->label('วันที่เผยแพร่')
    ->required();

Load the create form, save, then re-open the edit form. That single loop tells you whether display, storage, and hydration all agree — the thing most likely to surprise you.

Where to look first: the field classes' displayFormat() default (j M y, j M y H:i for the date-time variant) and the rendered markup in the browser. Since v4.1.0 the picker renders Filament's own Blade markup with Thai patches applied, so if you need to debug, start from Filament's date-picker view and compare, rather than hunting for a package-specific view.

Implementation Patterns

Pair the picker with a plain date in storage. The field is a display/input concern; keep the column a normal date/datetime cast on the model. Then format per-surface: the form uses ThaiDatePicker, while table columns and exports choose their own formatting deliberately.

Buddhist Era formatting is opt-in and token-driven. With v4.1.0 you can control the input format:

ThaiDatePicker::make('due_date')
    ->displayFormat('j F Y');   // 11 ตุลาคม 2569

Note Y yields the BE year (2569), not the Gregorian one. Use this when the field is read by Thai staff; leave the default if you are matching an existing UI.

Time-only fields are now a first-class pattern. On Filament 5.10.1+:

ThaiDateTimePicker::make('starts_at')
    ->date(false)   // time only
    ->seconds(false);

Before v4.1.0 this path was unreliable — the field could still render a date. Use it for opening-hours, shift, or appointment-time inputs where a date is implied by a parent record.

Lean on Filament's native date-limit API. v4.1.0 fixed limits syncing against Filament 5.10.1, so ->minDate(), ->maxDate(), ->disabledDates() and friends behave consistently with a stock DatePicker. Prefer them over custom validation rules — the picker UI and the server-side rule then share one source of truth.

Standard Filament reactivity works. Because the component is markup-compatible with Filament's own picker, ->live(), ->afterStateUpdated(), ->reactive() and ->hidden(fn (Get $get) => ...) compose normally. A common pattern is two fields where one gates the other:

ThaiDatePicker::make('end_date')
    ->minDate(fn (Get $get) => $get('start_date'))
    ->visible(fn (Get $get) => filled($get('start_date')));

Keep a single formatting helper for BE everywhere else. Table columns, PDFs, and notifications don't go through the form component. Centralise the BE conversion (a small ThaiDate::format() helper or a Carbon locale) so the form and the rest of the app don't drift.

Gotchas and Tips

The Filament version floor is the headline risk. v4.1.0 hard-requires filament/forms >= 5.10.1. Upgrading this package without bumping Filament leaves you silently pinned to 4.0.x, where ->date(false) is still broken. Order your composer update accordingly and re-test any time-only fields after the bump.

The Blade view changed shape. 4.1.0 replaced the package's forked view with Filament's own markup plus patches. If you published the package views or overrode them via ->view() / a theme, that override is now stale — diff it against the new markup or delete it and re-check the rendering. This is the most likely source of "works on my machine" visual regressions after upgrading.

Display format ≠ storage format. Changing displayFormat() is easy to test on create and forget on edit. After any format change, edit an existing record and save it untouched — confirm the value doesn't shift by a year, a day, or reset. BE years are a common culprit when the format used to parse differs from the format used to render.

BE years leak into comparisons if you format too early. Keep Carbon instances Gregorian until the last moment; only convert at render time. Sorting, whereBetween, and diff calculations on 2569 will quietly produce wrong results.

Defaults are unchanged on purpose. v4.1.0 did not touch the j M y default. Don't assume the upgrade will restyle your forms — nothing will look different until you opt in with displayFormat().

Test matrix worth keeping: create + edit round trip, time-only field, min/max date boundary, and one non-Thai locale user (in case your app is multilingual and the BE display should be conditional). Five browser checks catch nearly everything this package can break.

Extension point of choice is composition, not inheritance. Subclassing the field classes couples you to internal markup that just changed. Prefer configuring via displayFormat()/date()/native limits and wrapping repeated configurations in your own factory method or a custom Field subclass that only calls the public API.