Datetime Laravel Package

Product Decisions This Supports

• Framework bet, not a library bet. tempest/datetime is a read-only subtree split of the Tempest framework monorepo. The real decision it informs is "do we standardize on Tempest?" — not "should we add a datetime dependency?" Treat its existence as a data point in framework due diligence, not a standalone procurement.
• Build vs. buy for time handling. Every product eventually needs a testable clock (freeze time in tests, simulate DST transitions, deterministic billing cutoffs, SLA timers, reporting windows). This package is Tempest's native answer to that. Choosing it means not building your own clock abstraction and not pulling in Carbon/Chronos alongside the framework.
• Roadmap planning and upgrade cadence. There is no independent roadmap here — features, fixes, and breaking changes land in the upstream Tempest repo and flow down through the split. Release planning must key off framework versions, not this repository's tags. Budget for API churn proportional to framework pre-1.0 maturity.
• Risk register entry. 0 stars, 0 dependents, 0 dependents means zero external validation: no third-party usage to learn from, no community-authored extensions, no de facto stability guarantee. The bus factor is the framework's maintainer(s).
• Concrete use cases it would serve if adopted: timezone-correct scheduling and reminders, DST-safe recurring billing and invoicing, immutable date value objects in domain models, deterministic test suites via injected clocks, duration/interval math for subscriptions and trials.
• Contribution model decision. Because the split is read-only, any bug we hit is fixed upstream in the monorepo and mirrored here. That is a policy decision: are we willing to be a framework contributor, or do we need a vendor who will take our patches directly?

When to Consider This Package

Consider it when:

• You have already chosen Tempest, or Tempest is a finalist in an active framework evaluation and you are auditing component-level completeness.
• You want a framework-native, injectable clock abstraction rather than bolting Carbon onto a non-Laravel codebase.
• You are comfortable pinning versions and tracking an upstream monorepo for changelogs and security notes.
• Your team is prepared to file issues and PRs upstream rather than in this repository.

Look elsewhere when:

• You need a standalone datetime library with its own semantic versioning, independent release cadence, and community support. Use Carbon, Chronos, or brick/date-time; or plain DateTimeImmutable if your needs are simple.
• You are on Laravel. Carbon is already in the box, and Carbon::setTestNow() covers most frozen-time testing without a new dependency. Adding a second datetime abstraction to a Laravel app is a net negative.
• You need enterprise support, an SLA, security backport guarantees, or a documented deprecation policy.
• Your compliance surface (audit, financial reporting) requires a library with demonstrated production adoption. Zero dependents is disqualifying for that class of workload.

Adoption gate before any commitment: verify the upstream Tempest monorepo's commit recency, issue responsiveness, release history, and whether the datetime component is documented first-party. Judge the framework, not this mirror — the repository's own signals (0 stars, 0 dependents) are structurally uninformative because subtree splits do not accumulate community engagement.

How to Pitch It (Stakeholders)

To executives: This is not a purchasing decision — the package is MIT-licensed and costs nothing. It is a signal about a young PHP framework called Tempest, which ships its own datetime component as a read-only mirror of its main repository. Our recommendation is watchlist, not adopt: the component has no independent community, no third-party dependents, and no release cadence of its own, so adopting it means adopting the entire framework and its maturity risk. No action, no spend, no migration. We will re-evaluate if Tempest gains adoption or if we standardize on it for a greenfield service.

To engineering: tempest/datetime is a subtree split — read-only, MIT, PRs go upstream to the Tempest monorepo. It gives you a framework-native clock/timezone/duration layer, which is genuinely valuable for deterministic tests and DST-safe scheduling. The trade-off is coupling: version pinning follows framework releases, API churn is likely pre-1.0, and there is no external user base to lean on when something breaks. Do not introduce this into a Laravel codebase — Carbon already covers it. If we pilot Tempest, pilot this component with it and evaluate the clock abstraction and timezone handling as the acceptance test.

Recommendation: Do not adopt as a standalone dependency. Track it as part of framework due diligence; if Tempest is ever selected, revisit as a bundled component rather than an independent build-vs-buy choice.