Product Decisions This Supports
- Feature scoping for relative timestamps. Any surface that shows recency — activity feeds, comment threads, notification centers, audit logs, "last updated" columns, onboarding checklists — needs a humanized time string. This package answers "how do we render
3 minutes ago" so you can decide whether to invest in that UX at all, rather than arguing about implementation.
- Build vs. buy, honestly framed as buy vs. already-have. In a Laravel codebase this is not a real build-vs-buy call: Carbon ships with the framework and
diffForHumans() already does this. The decision this package should trigger is a duplication audit — do we want a second, parallel implementation of a solved problem in the dependency tree, and who owns keeping the two behaviors consistent?
- Localization roadmap input. If your product roadmap includes non-English markets, relative-time strings become localized copy, not code. Evaluating this package forces the question of where that copy lives (translation files vs. ICU/CLDR via Carbon) and who maintains it — a decision that outlives the package itself.
- Estate-wide consistency. If you run non-Laravel PHP services (legacy apps, small microservices, CLI tooling) alongside Laravel, this package gives one plain-PHP helper that works without booting a framework — a legitimate argument for standardizing on it across the estate rather than mixing Carbon and hand-rolled formatters.
- Dependency-risk triage. A single-class utility with a 2022 last release is a low-severity but real line item in a dependency-sprawl or abandonment review. The decision here is usually "keep, with a note" rather than "remove."
- Cheap, reversible bets. Because the API surface is tiny, adoption carries almost no lock-in cost. The migration off it is an afternoon, not a quarter. That makes it a safe enabler for UX polish you can ship now and revisit later.
When to Consider This Package
Adopt, or at least spike, when:
- The consuming code is plain PHP or a non-Laravel framework — no Carbon, no
diffForHumans(), and you don't want to pull in a date library for one helper.
- You need its specific translation coverage or output phrasing (e.g., its handling of "just now" and near-future dates) and matching Carbon's exact strings would mean rewriting copy across the product.
- You want a zero-integration helper: no service provider, no facade, no config publishing, no container coupling. Useful in scripts, workers, and shared libraries where framework bootstrapping is a smell.
- You are deliberately isolating formatting logic behind a thin, swappable seam — this is small enough to wrap and replace later without touching call sites.
Look elsewhere (or just use the framework) when:
- You are on Laravel 8+.
Carbon::parse($ts)->diffForHumans() covers the requirement with a dependency you already ship, test, and patch. Adding this package here is duplication, not leverage.
- You need timezone-correct, locale-correct, ICU/CLDR-compliant output at scale. Carbon's locale coverage and update cadence are stronger, and correctness bugs in relative time are user-visible.
- You require an actively maintained dependency — security patching, current PHP version support, a responsive maintainer. A 2022 last release on a 257-star package is a signal to verify PHP 8.2/8.3 compatibility yourself before committing, not an automatic disqualifier for a leaf utility.
- You need framework DX — Blade directives, config, facades, test helpers. You will be writing that glue yourself.
- The string appears in user-facing legal, billing, or SLA contexts where "about 1 hour ago" is not acceptable and you need exact timestamps anyway.
How to Pitch It (Stakeholders)
To executives: This is a small, free utility for turning raw timestamps into readable phrases like "5 minutes ago" — the kind of polish that makes feeds and activity logs feel finished rather than raw. Cost is effectively zero and the risk is contained: it is one class with a narrow surface, so if we ever want to remove it, that is a short task, not a migration project. Important caveat to set expectations: our Laravel stack likely already does this out of the box, so this is less a purchase decision and more a "confirm we're not paying twice for the same capability" decision. Recommendation: no budget, no new vendor, no commitment — a short engineering check, then a default to what we already have.
To engineering: It's a single-purpose PHP class that formats dates as relative strings, with no framework coupling and no service provider. Two things to weigh before we take it on: (1) Carbon's diffForHumans() already covers this in Laravel, so the real question is whether we have a non-Laravel surface that needs it or a concrete output/localization gap Carbon doesn't fill; (2) the last tagged release is mid-2022, so please confirm PHP version compatibility and skim the issue tracker before we depend on it. If we do adopt, wrap it behind a small internal formatter so the choice stays reversible and call sites never touch the library directly.