Weave Code
Time Continuum Laravel Package
innmind/time-continuum
InnMind Time Continuum is a PHP library for modeling time as a continuum of instants and intervals. It offers immutable temporal objects, precise duration arithmetic, comparisons, and conversions for scheduling and time-based domain logic.
At a glance
Frequently asked questions about Time Continuum
- Is innmind/time-continuum compatible with Laravel?
- It installs as a plain Composer package and can technically coexist in a Laravel codebase, but it has no Laravel awareness at all. There is no service provider, facade, config file, Eloquent cast, validation rule, or scheduler bridge. TimeContinuum would sit parallel to Carbon and Laravel's time handling, which means every seam between the two needs bespoke glue code that you own and maintain.
- Does innmind/time-continuum ship a Laravel service provider, facade, or Eloquent cast?
- No. The library is framework-agnostic and functional in style, exposing immutable instants and intervals plus monadic Maybe and Attempt return types. Nothing in the package knows about Laravel's container, facades, model attributes, or JSON resources. Any casts, DTO mapping, or form request integration must be written first-party, and there are no community recipes to copy because the package has zero dependents on Packagist.
- How do I install innmind/time-continuum and check it works with my Laravel version?
- Run composer require innmind/time-continuum on a throwaway branch and immediately watch the dependency resolution output. The package pulls in other Innmind libraries such as innmind/immutable and innmind/math, and their PHP constraints must resolve alongside your Laravel and Symfony constraints. Spike one round trip through an Eloquent cast, one timezone edge case, and one serialization check before any design discussion. Expect friction, and treat a clean install as only the first gate, not a green light.
- Is innmind/time-continuum still maintained?
- The repository is archived, which means no bug fixes, no security patches, no PHP version bumps, and no CVE response. It is a single-author ecosystem with roughly 28 stars and no downstream signal, so the bus factor is one. If you adopt it, any defect effectively becomes your defect. Verify activity against the VCS history rather than Packagist, since the release metadata appears future-dated and is not a reliable proxy for cadence.
- Can I replace Carbon with innmind/time-continuum in a Laravel app?
- No, not realistically. Laravel 10, 11, and 12 ship Carbon as a hard dependency, and the framework leans on it for Eloquent timestamps, the scheduler, cache TTLs, signed URLs, queue backoff, and test-time freezing. You cannot swap Carbon out, so TimeContinuum is at best additive. Use it only if you are deliberately carving out a functional core or hexagonal domain with an isolated time model.
- How do I use TimeContinuum with Eloquent models and casts?
- There is no built-in cast, so you write your own cast or adapter that converts between TimeContinuum's immutable instants and your datetime columns. The same adapter then has to cover model attributes, DTOs, form requests, and API resources, which is a meaningful amount of first-party code. Keep the import of innmind/time-continuum confined to a single adapter file so that removing it later is a one-file delete rather than a refactor.
- Does innmind/time-continuum handle timezones and calendars?
- Yes. Its core purpose is modeling time as a continuum of instants and intervals, with immutable temporal objects, precise duration arithmetic, comparisons, conversions, calendars, and timezones. The caveat is that Carbon already covers timezone handling, localization, and diffing for your application. The marginal capability TimeContinuum offers is API purity and richer point-in-time semantics, not functionality you currently lack.
- How does innmind/time-continuum compare to Carbon or CarbonImmutable?
- Both are immutable and both handle timezones, diffing, and localization, so the functional overlap is large. TimeContinuum's differentiators are its monadic Maybe and Attempt return types and a stricter functional API. Before adopting it, document the concrete business requirement that Carbon or Chronos cannot satisfy. For most teams that gap does not exist, and the evaluation stops there.
- Does TimeContinuum work with Laravel's Carbon::setTestNow test freezing?
- Only indirectly. Carbon::setTestNow freezes Carbon, and TimeContinuum has its own clock abstraction, so you would inject a fake clock into your adapter to control it in tests. That leaves you coordinating two separate test-time mechanisms in the same test suite. Factor that overhead into the cost of adoption, especially if your existing tests rely heavily on setTestNow.
- What are the production risks and exit strategy if I adopt innmind/time-continuum?
- The main risks are an archived repository with no security response, transitive Innmind dependencies with their own PHP ceilings, and a single maintainer with no downstream validation. The defensible posture is to define your own narrow Clock, Instant, and CalendarDate interfaces in the domain layer, back them with Carbon by default, and only add a TimeContinuum adapter inside one bounded context if a specific gap is proven. Import the package in exactly one file so you can fork, vendor, or delete it cheaply. If you cannot name who owns that fork when the maintainer is gone, do not adopt it.
Weaver
How can I help you explore Laravel packages today?