Datetime Provider Laravel Package

Product Decisions This Supports

• Time-dependent feature delivery. Trials, subscription renewal, proration, token/session TTLs, rate-limit windows, "time since" labels, scheduled notifications, SLA countdowns, and daily quota resets all depend on a single, trustworthy notion of "now." A request-scoped time provider is the seam that makes those features testable and deterministic.
• Consistency within a request. Audit trails, created_at/updated_at, log correlation timestamps, and multiple domain events fired in one transaction should resolve to the same instant. Without that, ordering bugs and flaky tests appear as "sometimes" failures that are expensive to diagnose.
• Timezone policy. Forces an explicit product decision: store UTC, render in the user's timezone, and have exactly one authoritative source of the request timezone (user profile vs. tenant vs. app default). This package's model — provider owns current date, time, datetime and timezone — is the right shape even if the code isn't.
• Roadmap items this unblocks or de-risks: scheduled billing runs, point-in-time ("as of date") reporting and snapshots, multi-region launch where day rollover defines quota resets, DST-sensitive cutoffs, month-end proration, business-day calculations.
• Build vs. buy signal. This is the canonical case where the pattern is the asset and the package is not. The capability is an interface plus two small implementations bound as a singleton; the market price is roughly one engineer-day, so the buy decision has to be justified by maintenance transfer, not by code volume.
• Use cases where it matters most: anything where a test must assert "at 23:59:59 on the last day of the month, the invoice is generated once," or where support needs to know exactly what the system believed the time was when it acted.

When to Consider This Package

• Only if you are on Nette Framework. Despite being filed as a Laravel/PHP package, this is a Kdyby Nette DI extension, not a Laravel service provider — there is no auto-discovery, no facade, no Laravel config publishing. On Laravel it would have to be wrapped and re-bound manually, at which point you have written the integration anyway.
• Only if you accept the maintenance profile. Last release February 2018, ~10 stars, zero dependents, and a NOASSERTION license that legal must review before it ships in a commercial product. There is no security response path and no compatibility work for modern PHP.
• Only if your codebase still centers on mutable DateTime. Modern equivalents (DateTimeImmutable, PSR-20 ClockInterface, symfony/clock, Carbon's setTestNow) cover the same ground with active maintenance.
• Look elsewhere or build in-house if: you are on Laravel (use a small Clock interface bound as a singleton, with SystemClock and FrozenClock, plus Carbon's test helpers); you are on Symfony (PSR-20 + symfony/clock); you need sub-second precision guarantees or monotonic time for benchmarking; or your only requirement is test freezing, which the framework already solves.
• Reconsider the pattern when: more than one team writes time-dependent code, you have recurring flaky tests around "now," or you need an auditable single source of time for compliance. In those cases copy the design, not the dependency.

How to Pitch It (Stakeholders)

For executives. The idea behind this package — one injected clock per request — is worth adopting; the package itself is not. It is an eight-year-old extension for a different framework, with single-digit stars, no dependents, no maintained release, and an unclear license. The recommendation is to build the equivalent internally in about a day: a Clock interface with SystemClock and FrozenClock implementations, bound once per request. That gives us deterministic tests for billing, trials, and scheduling, consistent timestamps across a request, and one explicit answer to "what timezone are we in?" — with no third-party maintenance or licensing exposure.

For engineering. This is a Nette DI extension, so adopting it on Laravel means writing our own binding regardless; the net saving is zero. The functional surface we actually need is small: a provider returning current date, time, datetime, and timezone, with the ability to freeze and advance time in tests. We replicate that as ~100 lines behind an interface, register it as a singleton, inject it wherever now() is currently called directly, and lint against new DateTime()/Carbon::now() in domain code. Benefits: no sleep() in tests, no midnight-flake in CI, consistent audit timestamps, explicit timezone source. Costs and risks: near-zero build cost, and we avoid an unmaintained dependency with a NOASSERTION license. Credit the original design in the ADR and move on.