- What is filament-nepali-datetime and what does it do?
- filament-nepali-datetime is a FilamentPHP plugin that adds Bikram Sambat (Nepali) date and time support to Filament form fields, infolist entries, and table columns and filters. It wraps Filament's existing DateTimePicker, TextColumn, and TextEntry components so the UI renders and accepts BS dates while your database keeps Gregorian (AD) values. It is a presentation-layer adapter, not a standalone calendar library, so it is installed via Composer alongside Filament. If your admin panel serves Nepali users who think in BS dates, this lets them enter dates naturally without changing your schema.
- How do I install rohanadhikari/filament-nepali-datetime?
- Install it with Composer using composer require rohanadhikari/filament-nepali-datetime, then swap the relevant Filament components in your resources for the package's Nepali-aware versions. Because it extends concrete Filament classes, no service provider registration or config publishing is typically required beyond standard Laravel package discovery. Check the repository README for the exact component class names and any panel plugin registration step for your Filament version. You should verify the installed Filament major matches the constraint in the package's composer.json before you start.
- Which Filament versions does this package support, v3 or v4?
- The package is built by wrapping Filament's DateTimePicker, TextColumn, and TextEntry classes, so its compatibility is tied to whichever Filament major its composer.json constraint allows. Always read the composer.json constraint rather than assuming, and note whether it uses a caret range like ^3.0 (bounded) or a wildcard (open-ended and unsafe). Wrappers over Filament component internals are the most upgrade-fragile part of the stack, so expect breakage on minor Filament releases as well as majors. Pin your Filament version and test the upgrade in a branch before bumping.
- Does this package store Nepali (BS) dates in the database or Gregorian (AD) dates?
- The intended design is that Gregorian (AD) values remain canonical in your database and conversion happens only at the presentation boundary, which keeps your schema free of calendar coupling. That means your migrations, model casts, validation rules, and API resources should stay AD-only. Avoid writing BS strings into date columns, because every query, sort, aggregate, and report outside Filament will then be operating in the wrong calendar. Confirm this behavior in your own spike before relying on it, since the package does not own your persistence layer.
- How do I use a Nepali date picker in a Filament form?
- Replace the standard Filament date picker in your form schema with the package's Nepali datetime picker component, keeping the same field name and validation you already use. The component handles rendering BS dates in the input and converting the submitted value back to AD for your form state and model. Because it is a component wrapper, existing reactive behavior, required rules, and dependent fields should continue to work as before. Test round-trips carefully around midnight and month boundaries, where hydration and dehydration cycles are most likely to drift.
- Can I show a Nepali date column and filter in a Filament table?
- Yes. The package provides a Nepali-aware text column and integrates with Filament table filtering so records display as BS while the underlying stored value stays AD. The important caveat is the query layer: sorting, date-range filters, and aggregate widgets operate on raw AD values, so verify that filter input is converted back before it hits the query. If it is not, users could filter on one calendar and sort on another, which produces confusing results. Test range filters spanning BS month boundaries specifically.
- What Bikram Sambat year range does the converter support?
- BS month lengths are irregular, ranging from roughly 29 to 32 days and driven by sidereal calculations, so conversion requires authoritative per-year lookup tables rather than arithmetic. Any shipped table has a finite horizon, commonly something like 1970 to 2100 BS, and dates outside that window are typically wrong silently rather than throwing an exception. Check the repository for the exact supported range at both ends and treat out-of-range input as a validation case you handle yourself. If you need dates beyond the shipped tables, you will need a different conversion source.
- How does the package handle the Nepal timezone (UTC+05:45)?
- Nepal runs on UTC+05:45 with no daylight saving, a non-hour offset that makes 'today' in Kathmandu a different calendar day from 'today' in UTC for 5 hours 45 minutes each day. Whether the package uses config('app.timezone'), a hardcoded Asia/Kathmandu, or UTC is the contract you need to confirm, because it decides what a server-side default of now() or today() produces. Be explicit about timezone handling in your own code rather than relying on implicit behavior. Set your application timezone deliberately and assert the boundary case in a test.
- Can I reuse the BS to AD conversion outside of Filament, for APIs or validation?
- Not cleanly, by design. The package exposes calendar logic only through UI components that wrap Filament classes, so exports, API resources, validation rules, and Artisan commands cannot reuse it without duplicating conversion code. Treat it as a Filament UI adapter and plan to own a first-class conversion service separately if you need conversion elsewhere. A small internal service or a maintained BS conversion library, wrapped behind your own interface, keeps the dependency direction correct and lets you swap implementations later.
- Is filament-nepali-datetime production-ready and actively maintained?
- It is a small, MIT-licensed package with a narrow surface area of three components and no dependents, maintained by a single author with limited public adoption, so there is no evidence of behavior under real traffic, multi-tenancy, or Filament minor upgrades. That does not make it unusable, but it does mean you should treat it as a component you own the risk for. Run an afternoon spike, check for a test suite that asserts against an independent authoritative BS reference, and pin versions. If conversion correctness is business-critical, consider owning the conversion logic and keeping the package as thin presentation only.