Filament Ethiopic Calendar Laravel Package

Product Decisions This Supports

• Market-entry / localization sequencing. Whether to invest in an Ethiopian or Eritrean user base for internal tooling. If operators, finance staff, or government/NGO counterparts read dates in the Ethiopic calendar, a Gregorian-only admin panel is a friction point — and this package is a cheap probe to test whether closing it moves adoption or support-ticket volume.
• Feature scoping: is "calendar display" the whole requirement, or the thin edge of an i18n program? This package is display-only for Filament table columns. If it proves valuable, the real roadmap item is broader: Ethiopic date pickers and inputs, validation, filter ranges, CSV/PDF export headers, and reporting periods aligned to the Ethiopian fiscal year (Hamle 1 – Sene 30, ~July 8 – July 7). Decide up front whether you are buying a convenience or committing to a localization track.
• Build vs. buy (vs. build-on-top). The underlying work is date conversion plus month names and the 13th month, Pagume. That is a well-understood problem with existing conversion libraries. The package's marginal value is Filament integration conventions; a PM should treat this as a reference implementation to evaluate, not a dependency to standardize on.
• Architecture guardrail decision. Establish the rule now: store UTC/Gregorian, render Ethiopic. Any package that bleeds localized formatting into persistence or query logic (filters, sorting, aggregates) is disqualified regardless of convenience. This package stays in the presentation layer, which is the right shape.
• Risk-tiering and procurement. With 2 stars, 0 dependents, and a single maintainer, this sits in the "evaluate and be prepared to vendor" bucket. That's an explicit decision — owning a fork — not an accident to discover at the next Filament major upgrade.
• Prioritization sanity check. If you have no Ethiopian deployment, no Ethiopian-diaspora customer segment, and no contractual localization requirement, this is a zero-priority item. If you have any of those, table-level date display is a low-cost, visible quality signal.

When to Consider This Package

Adopt / trial when:

• You run Filament admin panels (verify the supported Filament major version first — this is the most common breakage axis) and the requirement is genuinely display-only.
• Stakeholders in Ethiopia or Eritrea consume your internal dashboards, or the customer-facing team fields recurring "what date is this?" questions.
• You want a one-to-two-day spike to validate demand before committing engineering time to an in-house formatter.
• Your data model already stores Gregorian/UTC and you only need a rendering change with no migration.

Look elsewhere when:

• The requirement extends past tables. Date pickers, form inputs, filter ranges, export headers, PDFs, public sites, APIs, or mobile clients all need a shared conversion layer behind your own interface — a Filament column plugin won't cover them and will fragment the logic.
• You need real localization breadth. Amharic, Tigrinya, Oromo, and English formatting, numerals, and time conventions are unlikely to be covered at this maturity level. Verify before assuming.
• Procurement or security review applies. Single-maintainer, near-zero-adoption packages typically fail enterprise vendor review and rarely survive an SLA conversation. Plan to fork and own it, and price that in.
• Date arithmetic is financially or legally load-bearing — interest accrual, contract terms, statutory deadlines. Pagume and leap-year boundary handling must be verified with your own tests before you trust any third-party converter.
• You aren't on Filament at all. This solves a problem you don't have.

Regardless of choice: pin the version, wrap the converter behind your own interface, and write tests for Enkutatash (Sept 11 / Sept 12 in the year preceding a Gregorian leap year), Pagume length, and year-boundary offsets (~7–8 year gap from Gregorian).

How to Pitch It (Stakeholders)

For executives: This is an MIT-licensed, low-cost option to test whether showing dates in the Ethiopian calendar improves usability for our Ethiopian users. It changes presentation only — all data stays in standard Gregorian/UTC, so reporting, integrations, and historical records are unaffected. The cost is a short evaluation, not a platform commitment. The risk is maintenance: the project is small and effectively single-maintainer, so we should assume we may need to own a fork; that's a contained, one-file-scale risk given the narrow scope.

For engineering: It's a Filament column formatter — no schema, storage, or query changes. The only substantive logic is Gregorian↔Ethiopic conversion, including the 13th month and leap-year behavior; everything else is formatting. Treat it as a reference implementation: wrap the conversion behind our own service so we can swap or vendor the package without touching call sites. Add tests for Pagume, Enkutatash, and year-boundary offsets, and confirm the supported Filament major version before we install it. If our needs grow beyond table display — inputs, filters, exports, non-Filament surfaces — we should build the shared conversion layer directly rather than extend this.