- How do I install the rohanadhikari/nepali-date package in a Laravel app?
- Install it with Composer using composer require rohanadhikari/nepali-date. Laravel package auto-discovery registers the service provider, and the package also exposes a facade alias plus optional config publishing for defaults. AfterInstall, confirm the resolved PHP and illuminate/support constraints with composer show rohanadhikari/nepali-date so you know exactly which version you locked in. Nothing else is required, since the library has no I/O, network, or persistence concerns.
- Which Laravel and PHP versions does this Nepali date package support?
- The package is a dependency-light, pure-PHP library with a Laravel glue layer built on illuminate/support, so support is bounded by its Composer constraints rather than by deep framework coupling. Check the require block and the repository CI matrix before adopting it, and pay particular attention to the Illuminate range and any Carbon 2 versus Carbon 3 constraint. If your application runs Laravel 10, 11, or 12 on PHP 8.1+, verify those combinations explicitly with composer why-not rather than assuming they are covered. Treat the version matrix as part of your adoption spike.
- How do I convert a date between AD (Gregorian) and BS (Bikram Sambat)?
- The package provides AD-to-BS and BS-to-AD conversion through its facade and helper API, so a single call returns the corresponding date in the other calendar. Conversion is table-driven against BS month lengths, which range from 29 to 32 days, so results are deterministic for any year inside the supported window. Keep conversions at the edges of your application, such as form rendering, request validation, and API resource serialization, and keep canonical timestamps in AD/UTC internally. This avoids leaking a calendar representation into your domain model or query layer.
- Can I use an Eloquent cast to display Nepali dates on a model?
- Yes, the package ships Eloquent casts so a model attribute stored as an AD date can be presented as a Bikram Sambat date without custom accessor code. The correct pattern is to persist the canonical UTC/AD timestamp or date column and let the cast handle presentation only, so sorting, indexing, and range queries continue to work normally. Do not persist BS strings as the system of record, because irregular BS month lengths make comparisons and date arithmetic unreliable at the database level. If you need both calendars in an API response, serialize the AD value as canonical and add the BS value as a derived field.
- Does the package provide Blade directives or validation rules for Nepali dates?
- Blade directives are included for rendering Nepali-formatted dates in templates, which keeps localization logic out of your views' PHP blocks. Validate BS input coming from forms with your own rule or a package-provided rule if available, and always normalize to AD before persisting. Because BS month lengths vary and day boundaries do not align with UTC midnight, validation must reject impossible day values for the specific BS month and year, not just check a numeric range. Nepal's fixed UTC+05:45 offset with no DST simplifies this, but the day-boundary rule should still be documented explicitly.
- Should I store Nepali (BS) dates or English (AD) dates in the database?
- Store canonical timestamps in UTC or AD in the database, and convert to Bikram Sambat only at the presentation and input boundaries. Persisting BS strings as the system of record creates sorting, indexing, range-query, and reporting problems that no library can fix, and it complicates integration with any tooling that expects Gregorian dates. Keep the conversion behind an internal CalendarService contract or a NepaliDate value object so the vendor package is the sole implementation and a fork or in-house table swap stays cheap. This is also the safest posture if the package is ever abandoned.
- What is the supported BS year range, and what happens outside it?
- BS month lengths are driven by a hardcoded lookup table per year, which is the standard implementation but also bounds the range of years the package can convert correctly. The exact window is defined by that table in the source, so read it and test the first and last supported years explicitly before going to production. The key question for the maintainer is whether out-of-range input throws an exception or silently returns a plausible but wrong date, since the latter can produce incorrect values on invoices, contracts, and statutory filings. Confirm the authoritative source of the table and how corrections are handled when a panchang dispute arises.
- Does it format dates in Nepali and handle Devanagari numerals?
- Yes, the package supports Nepali date formatting, including Nepali month and weekday names and Devanagari numeral output, which is the main reason to use it over hand-rolled conversion code. Devanagari numeral parsing on input is a separate concern, so validate and normalize any user-supplied Devanagari digits before passing them to the converter. If you expose both calendars in one API, format the BS string on the resource layer only and leave the stored value untouched. Keep formatting concerns out of your models so the display locale remains a presentation decision.
- Is this package safe to depend on, and what are the alternatives?
- The technical risk is low because the library has no network calls, no persistence, and effectively no attack surface, but the maintainer and bus-factor risk is real: it is a single-maintainer project with negligible community and no commercial backing. Mitigate this by wrapping it behind your own CalendarService contract or NepaliDate value object so you can swap to a fork or an in-house month-length table in about a day. Alternatives are other BS conversion libraries or your own table, and in every case the deciding factor is the sourcing and maintenance of the month-length data, not the API surface. Build your own golden-file test suite rather than relying on community validation.
- How should I test AD-to-BS conversion in my application?
- Create a golden-file fixture suite of a few hundred AD and BS pairs sourced from an authoritative calendar, spanning year boundaries, month ends, and 29, 30, 31, and 32-day BS months. Add round-trip property tests that convert AD to BS and back, plus explicit tests for the first and last supported BS years and for out-of-range behavior. Assert that out-of-range input fails loudly rather than returning a plausible wrong date, and pin the package version so a silent table change cannot alter fixtures unnoticed. Because Laravel validation and Eloquent casts sit on top of the converter, test them through HTTP request and model round-trip tests as well.