Datetime Provider Bundle Laravel Package

Technical Evaluation

Architecture fit — poor. The package is a Symfony bundle (DateTimeProviderBundle), not a Laravel package. It ships a Symfony Bundle class plus a DI compiler pass to register Kdyby\DateTimeProvider\Provider\CurrentProvider and related services into the Symfony container. Laravel has no bundle concept: it would not auto-discover, its Extension/CompilerPass hooks would never fire, and none of its service definitions would land in Laravel's container. Nothing in the repo targets Laravel's ServiceProvider, facades, or config publishing.

Functional overlap is total. What the underlying kdyby/datetime-provider library provides — an injectable DateTimeProvider interface returning "now" so time can be frozen in tests — Laravel already solves natively via Carbon's test clock (Carbon::setTestNow(), Illuminate\Support\Facades\Date::setTestNow()), and ecosystem-standard via psr/clock / symfony/clock. Adopting this package would add a second, parallel time-abstraction to the codebase with no capability gain.

Integration feasibility — low. There is no adapter layer available, and writing one means porting a Symfony compiler pass into a Laravel service provider for a library whose entire public surface is roughly "one interface, two implementations." The integration cost exceeds the cost of reimplementing the abstraction in ~40 lines.

Technical risk — high relative to value.

The NOASSERTION license alone is a hard gate in most orgs. Combined with zero dependents and no releases since 2019, this fails a basic supply-chain bar.

Key questions for the team:

1. What concrete requirement is not already met by Carbon::setTestNow() or a PSR-20 Clock binding?
2. Are there call sites using bare new \DateTime() / time() that we're trying to make testable? If so, that's a refactor task, not a dependency decision.
3. Can legal clear NOASSERTION, and is that worth it for a non-Laravel bundle?
4. Does the requester actually need the Symfony bundle, or just the kdyby/datetime-provider interface as a naming convention?

Integration Approach

Stack fit: none. PHP version compatibility is the only shared ground; the framework-level contract is Symfony-specific and does not map to Laravel's container lifecycle.

Recommended path: do not install. Replace the intent, not the package.

1. Adopt the standard contract. Bind Psr\Clock\ClockInterface (via symfony/clock or a trivial in-house implementation) as a singleton in AppServiceProvider. For test-time control in an existing Carbon-centric codebase, prefer Date::setTestNow() and avoid a second abstraction.
2. If the DateTimeProvider shape is genuinely preferred, port it locally: define App\Support\Clock\DateTimeProvider (one now(): DateTimeImmutable method), implement SystemProvider and FrozenProvider, and register the binding in a service provider. This is a small, owned, MIT-clean artifact with no upstream dependency.
3. Refactor call sites incrementally. Inventory now(), Carbon::now(), new \DateTime(), and time() usage; inject the clock into services that need deterministic time; leave framework internals alone.

Compatibility. The 2019 release predates PHP 8.x and Symfony 5+; if any transitive requirement forces it in, expect composer resolution conflicts against a modern Laravel application. Do not attempt to force-install under --ignore-platform-reqs — that converts a clean refusal into a latent runtime fault.

Sequencing.

• Week 0: rule out the package on license + framework mismatch; close the ticket with rationale.
• Week 1: define/confirm the clock contract and bind it; add a test helper for freezing time.
• Weeks 2–3: migrate the highest-churn services (billing, scheduling, expiry logic) to injected time.
• Ongoing: lint rule or static analysis to block new bare now() in domain code.

Operational Impact

Maintenance. Near-zero if not adopted; if adopted, effectively total — you would own the code the moment you fork it, because upstream has not shipped since 2019 and has no dependents to surface breakage.

Support. No vendor, no maintainer SLA, no CVE process. NOASSERTION licensing means unclear redistribution rights, which is an audit finding waiting to happen.

Scaling. Runtime footprint is trivial (a wrapper around DateTimeImmutable) — scaling is a non-issue. The scaling problem is organizational: every additional time abstraction multiplies the ways tests can be non-deterministic and the ways engineers can disagree about "now."

Failure modes if adopted anyway:

• Bundle never registers; container has no DateTimeProvider binding → runtime BindingResolutionException at first resolution, likely in a request path, not at boot.
• Container resolves the service but a Symfony-only dependency (e.g., symfony/dependency-injection compiler-pass API) breaks on a major bump → fatal error during composer update in CI or, worse, in production.
• Test determinism silently lost: some code paths use the injected provider, others use Carbon::now(), so frozen-time tests pass for covered services and intermittently fail elsewhere.
• Unpatched transitive dependency surfaces in a security scan and blocks a release train.

Ramp-up. Low for the alternative (a clock binding is a well-understood pattern most PHP engineers have seen); high for the package itself, because a new engineer must learn a Symfony-flavored abstraction that exists nowhere else in the stack and is documented only by a 2019 README.

Verdict: Reject. Score 0.06, 6 stars, 0 dependents, dormant since 2019, unresolved license, and a framework mismatch against Laravel all point the same way. The underlying need — injectable, freezable time — is real and should be met with psr/clock or Carbon's test clock, both of which are already in or adjacent to the stack.