Time Continuum Laravel Package

Technical Evaluation

Architecture fit. innmind/time-continuum is a framework-agnostic, functional-style time abstraction library (immutable point-in-time values, calendars, timezones, Maybe/Attempt return types). It has no Laravel awareness: no service provider, no facade, no Eloquent cast, no validation rule, no scheduler bridge. In a Laravel application the time layer is already load-bearing across Eloquent timestamps, Illuminate\Support\Carbon, the scheduler, cache TTLs, signed URLs, queue backoff, and Carbon::setTestNow. TimeContinuum would sit parallel to all of that, requiring two-way adapters. It only fits if you are deliberately carving out a functional core / hexagonal domain with an isolated time model — a niche posture for a Laravel codebase.

Integration feasibility. Low. The API is monadic and immutable, so every Laravel seam (casts, model attributes, DTOs, form requests, JSON resources, job dispatching) needs bespoke glue. With zero dependents on Packagist there are no community recipes, no third-party service providers, and no reference implementations to copy. Integration cost is entirely first-party R&D, not configuration.

Technical risk. High and concentrated:

• Archived — no bug fixes, no security patches, no PHP version bumps, no CVE response. Any defect becomes our defect.
• Ecosystem dependency — it pulls in other Innmind packages (innmind/immutable, innmind/math, etc.) which carry their own maintenance posture and PHP-version ceilings that will eventually collide with Laravel's requirement matrix.
• Bus factor 1 — 28 stars, single-author ecosystem, no downstream signal.
• Duplication, not capability — Carbon 2/3 already covers timezone handling, localization, diffing, and test-time freezing; the marginal capability is API purity, not functionality.
• Future-dated release metadata (2026-01-18) suggests release tags are not a reliable proxy for cadence; verify against VCS history, not Packagist.

Key questions. Why was the repo archived, and what (if anything) supersedes it? What is the maximum supported PHP version, and does it install cleanly against our Laravel/PHP/composer constraint set? Are the transitive Innmind dependencies actively maintained? What concrete business requirement cannot be met by Carbon/Chronos? What is the exit cost if we adopt and later abandon — is the API small enough to fork and vendor? Who owns the fork if the maintainer is gone?

Integration Approach

Stack fit. Poor as a primary time library; plausible only as an internal domain primitive behind an owned interface. Laravel 10/11/12 ship Carbon as a hard dependency with deep framework coupling — you cannot swap it out, so TimeContinuum is at best additive.

Migration path. Do not adopt as a dependency of the application. If the domain genuinely needs richer calendar/point-in-time semantics, the defensible path is:

1. Define our own narrow interface (Clock, Instant, CalendarDate) in the domain layer.
2. Ship a Carbon-backed default implementation that satisfies 100% of current needs.
3. Only if a specific gap is proven, implement a second adapter over TimeContinuum inside one bounded context.
4. Import innmind/time-continuum in exactly one file (the adapter) so removal is a one-file delete.

Compatibility. Must be validated against the exact PHP/Laravel/composer matrix before any design discussion — specifically whether Innmind's psr/* and PHP constraints resolve alongside Symfony/Laravel constraints. Assume they will eventually diverge on the next PHP major.

Sequencing.

• Gate 0 (½ day): spike a throwaway branch — composer require, one round trip through an Eloquent cast, one timezone edge case, one serialization check. Expect this to fail or produce friction.
• Gate 1 (1 day): document the concrete capability gap vs. Carbon. If none, stop.
• Gate 2: only if a gap is proven, build the interface + adapter seam and gate it behind config.
• Gate 3: never retrofit existing code; new bounded context only.

Realistically most teams terminate at Gate 1.

Operational Impact

Maintenance. Archived status transfers all maintenance to us from day one. The library is small enough to fork and vendor under MIT, which converts an unmaintained dependency into an owned asset — but that is a standing engineering commitment, not a free win. Every PHP upgrade becomes a manual port.

Support. None. No issue triage, no security advisories, no upgrade guides. SCA/security tooling will flag it as unmaintained, which creates friction in audits and enterprise procurement reviews.

Scaling. Technically a non-issue — time arithmetic is CPU-trivial and stateless, no throughput or memory concerns. The real scaling problem is team scaling: a monadic, immutable API is a permanent cognitive tax on a Laravel team fluent in Carbon's imperative style, and every new hire pays it again.

Failure modes.

• Silent timezone drift at the Carbon↔TimeContinuum boundary (two "now" sources).
• Unwrapped Maybe/Attempt producing runtime exceptions in request paths.
• Eloquent/JSON serialization mismatches (TimeContinuum values are not Carbon, so toJson, toArray, diffForHumans, date casting all break).
• Carbon::setTestNow not propagating, producing flaky or time-dependent tests that pass locally and fail in CI.
• Composer resolution breakage on the next PHP or Laravel major, with no upstream fix path.
• Bus-factor-1 abandonment mid-initiative.

Ramp-up. 2–5 engineer-days for a senior PHP developer to become productive with the functional API plus the adapter seam; 5–10 days for the team to be collectively safe with it. Compare against near-zero for Carbon, which every Laravel developer already knows.

TPM recommendation: do not adopt as a dependency. The score (2.63), archived status, zero dependents, and overlap with Carbon all point the same direction. Leverage it as a design reference — the immutable value-object and explicit-calendar modelling choices are worth borrowing — and implement any genuinely needed capability as a thin, owned abstraction over Carbon. If a concrete gap later proves the need, fork under MIT into a vendored, internally-owned package with a named owner and a documented removal plan.