Chhankitek Laravel Package

Product Decisions This Supports

• Khmer-market localization — the core use case: rendering the Cambodian lunar date (Chhankitek) alongside the Gregorian date in apps, dashboards, receipts, and notifications. This is table-stakes parity work for any consumer product localized for Cambodia; without it, the product feels foreign to users who schedule life around lunar dates.
• Feature scoping for content & publishing — daily "today's lunar date" widgets, holiday countdowns, and push notifications for Buddhist observance days (Meak Boche, Visak Boche, Pchum Ben, Khmer New Year). Cheap to build once the conversion layer exists, high engagement value in-market.
• Scheduling and booking surfaces — wedding/ceremony planners, temple event calendars, and astrology-adjacent products depend on selecting auspicious lunar dates. This package supports the date conversion primitive, not the auspiciousness logic; scope accordingly.
• Roadmap gating — a defensible way to answer "can we ship a Cambodia edition this quarter?" If a lunar-date requirement blocks a launch or a partner integration (telco, bank, government), this package converts a multi-week algorithm project into a days-long integration.
• Build vs. buy — the real comparison is not "this package vs. a competitor" but "this package vs. an engineer reimplementing Khmer calendar rules from published references." The algorithm is non-trivial (leap-month insertion, multi-day lunar cycles, timezone-sensitive day boundaries), so a working MIT-licensed implementation has real option value even at low adoption.
• Portfolio triage — with 0 dependents and 12 stars, adopting this is a contained bet, not a platform commitment. That framing is what lets you approve it without an architecture review.

When to Consider This Package

Adopt when all of the following hold:

• Cambodia (or Khmer diaspora) is an actual target market with a funded roadmap item, not a hypothetical.
• The need is Gregorian → lunar display/conversion only. If you also need lunar → Gregorian, holiday datasets, or auspicious-date scoring, this covers a fraction of the requirement.
• You can afford a small golden-test suite validated against an authoritative source (Cambodian government holiday gazette, a recognized temple/calendar reference, or a second independent implementation). Treat correctness of date output as a launch blocker, not a QA nice-to-have.
• You wrap it behind your own LunarDateService interface so a wrong result or an abandoned package is a one-file swap.

Look elsewhere or build in-house when:

• You need a supported, SLA-backed dependency — a 12-star, 0-dependent package with effectively a single maintainer cannot carry a revenue-critical date feature. Vendor risk is the dominant cost, not the license (MIT is fine).
• Your stack isn't Laravel, or your Laravel/PHP version is outside the package's tested matrix. Verify framework constraints and PHP version support before estimating.
• You need it on the client side (JS/mobile) as well as the server — you'd be shipping two implementations and two correctness risks.
• You require rigorous historical or far-future date ranges, or precise handling of day-boundary/timezone rules for users outside Asia/Phnom_Penh.
• Due diligence flag: the listed last-release date (2026-09-02) post-dates the present, and the package has no downstream dependents. Verify release history, commit cadence, open-issue responsiveness, and test coverage directly on the repository before treating it as maintained. Metadata anomalies are a reason to inspect, not automatically to reject — but do not skip the check.

How to Pitch It (Stakeholders)

One line: A small MIT-licensed Laravel package that converts standard dates into the Khmer lunar calendar — the minimum viable primitive for any credible Cambodia-facing product.

For executives: Cambodia is a market where the lunar calendar is not decorative — it governs holidays, ceremonies, and scheduling. Supporting it is a market-entry cost, and this package reduces that cost from an engineering project to an integration task. The license is permissive and the scope is narrow, so the downside is bounded: worst case we spend a few days and replace it. The upside is unlocking a localized experience without asking for a headcount.

For engineering: Treat it as an untrusted dependency by design. Wrap it in an internal interface, pin the version, and gate the PR on a golden-test suite checked against an authoritative Khmer calendar source. Review the repo for maintenance signals (commit cadence, tests, issue response) before committing — adoption is effectively zero today, so we are the first real user and should budget accordingly. Expect to own bug fixes ourselves; the value we're buying is the algorithm, not the support contract.