Clock Laravel Package

Product Decisions This Supports

• Testability of time-dependent features. The core product value is not the clock itself — it is the ability to inject time instead of calling now() inside domain code. That single decision unlocks deterministic tests for anything the roadmap touches that has a temporal edge: subscription trials, proration and billing cutoffs, coupon windows, token and session expiry, SLA timers, rate-limit windows, "as of" reporting, and aging/collections views.
• Roadmap sequencing: abstraction layer vs. features. Adopting a clock abstraction is a horizontal investment that pays back across every time-sensitive feature. The PM decision is whether to pay that tax now (small, one-time, low risk) or keep accruing per-feature test flakiness and production "it worked at 11:59pm" incidents.
• Build vs. buy. This package is a thin utility (a few simple clock operations), MIT-licensed, with a small surface area. Realistically the build cost is measured in hours, not sprints — which means the honest comparison is this dependency vs. Carbon/setTestNow vs. a PSR-20 clock binding, not this dependency vs. building a time service from scratch.
• Framework direction. The package is from the Tempest PHP ecosystem, not Laravel. For a Laravel product this is a signal about ecosystem fit, not a feature decision — treat it as evidence that PSR-20-style clocks are becoming table stakes, not as a candidate dependency.
• Vendor and integration risk assessment. Zero stars, zero dependents, and a low opportunity score mean there is no community validation, no downstream battle-testing, and no observable maintenance track record. That is a legitimate input to a "do we let this into our dependency graph" decision, especially for anything touching money or entitlements.

When to Consider This Package

Consider it only when all of the following hold:

• The codebase is already on Tempest PHP (where this fits idiomatically), not Laravel or Symfony.
• You want a minimal, framework-native clock with no Carbon dependency and no timezone-heavy requirements.
• Your team is comfortable vendoring or forking a small MIT package and owning it, because the maintenance signal is effectively zero.
• The blast radius is contained — internal tooling, a prototype, or a bounded service — not a payments path with compliance review.

Look elsewhere (or just implement the pattern directly) when:

• You are on Laravel. Illuminate\Support\Carbon::setTestNow() / Carbon::setTestNow() already gives deterministic time in tests, is battle-tested, and adds no new dependency. Pair it with a container-bound Clock interface if you want the seam.
• You want standards alignment. psr/clock plus symfony/clock offers a widely adopted interface, a MockClock for tests, and long-term backing. That is the low-risk default for a Laravel/Symfony shop.
• You need more than "a few simple operations." Timezone-aware business rules, DST edge cases, monotonic/elapsed-time measurement, fake sleep, or scheduler integration are all out of scope here.
• Support and longevity matter. No stars and no dependents means no issue triage, no security advisories, no guarantee the API survives. Any org with a dependency-review or SBOM process should expect this to be flagged.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated tempest/clock, a small MIT-licensed time utility from the Tempest PHP ecosystem. The package itself is not the takeaway — it is a thin wrapper with no adoption (zero stars, zero dependents) and no maintenance track record, so it is not something we should put on our dependency graph today. What it validates is a cheap, high-leverage engineering pattern: stop reading the system clock inside business logic and inject time instead. That pattern makes time-sensitive features — trials, billing cutoffs, expirations, SLAs, reporting — deterministic to test and safer to ship, and we can get it from libraries we already depend on (Carbon / PSR-20 clock) at roughly a day of engineering effort and no new vendor risk. Recommendation: adopt the pattern, decline the dependency.

To engineering (short form): Treat this as a reference implementation, not a dependency. If we want the seam, bind a Clock interface in the container backed by psr/clock + symfony/clock, and use Carbon::setTestNow()/MockClock in tests. Migration is mechanical: replace inline now() calls in domain and service code with the injected clock, start with the highest-risk paths (billing proration, trial expiry, token TTL), and leave framework internals alone. If we were ever on Tempest, this package would be a reasonable starting point — but even then, budget for forking it and owning it, because nobody else is.