- Is tempest/datetime a Laravel package, or do I need a service provider?
- It is not a Laravel package. tempest/datetime is a read-only sub-split of the datetime component from the Tempest framework, so it ships no service provider, facade, config file, Eloquent casts, validation rules, or Blade directives. Anything Laravel-shaped, such as casts, Carbon bridges, or formatting helpers, is code you write and maintain yourself. Treat it as a standalone utility library wrapped in your own integration layer.
- Can I install tempest/datetime standalone without the Tempest framework?
- That is the first thing to verify before adopting it. The sub-split may pull in tempest/support or other framework primitives that assume a Tempest kernel, container, or attribute discovery, which quietly drags non-Laravel framework surface area into your app. Run a clean Composer install in an empty Laravel project and inspect the dependency tree before committing. If it requires the framework, the fit drops considerably.
- Does tempest/datetime integrate with Eloquent casts?
- Not out of the box. You would need to write your own CastsAttributes implementations for each persisted date type, plus serialization adapters for JSON and API boundaries. Budget two to three times the library evaluation effort for that seam, including parity tests against Carbon behaviour. The effort lives in the adapter layer, not in the library itself.
- How does tempest/datetime compare to Carbon and CarbonImmutable?
- The overlap is large: both give you immutable, timezone-aware date and time values with parsing and formatting. tempest/datetime leans on ext-intl for locale- and calendar-aware behaviour, so its differentiator is likely non-Gregorian calendar support and locale-correct formatting rather than basic date math. Carbon is already wired into Eloquent, now(), the scheduler, validation, and Blade in every Laravel app, so replacing it buys you very little for a lot of adaptation work.
- What PHP version and extensions does tempest/datetime require?
- Check composer.json in the repository for the exact constraint, since the package listing does not state a minimum PHP version. ext-intl is effectively a hard requirement because correctness depends on ICU for locale and calendar data. Pin matching ICU and timezone database builds across local, CI, and production so DST and formatting edge cases do not diverge.
- Is tempest/datetime stable enough to use in production?
- Assume churn: Tempest is pre-1.0, so class names, method signatures, and parsing semantics should be treated as unstable until a 1.0 release. Pin an exact version and schedule upgrades as planned work rather than floating the constraint. For a bounded domain utility behind your own interface it is reasonable; as a load-bearing dependency in revenue-critical scheduling, keep a fallback plan.
- Why does the tempest/datetime repository show zero stars and no dependents?
- Those numbers are artifacts of the sub-split, not quality signals. Consumers install the framework distribution or the monorepo, and issues and pull requests are routed to tempestphp/tempest-framework. You cannot judge health from the split repository alone, so read the parent repo for release cadence, maintainers, and deprecation policy.
- How do I convert between tempest/datetime objects and Carbon in Laravel?
- You own that bridge. Laravel hands you CarbonImmutable from the scheduler, now(), queue payloads, signed URLs, and cache TTLs, so write explicit to-and-from conversions at those boundaries rather than passing Tempest types inward. Keep Carbon as the default boundary type and confine tempest/datetime to the domain code where its semantics actually pay off.
- How do I handle timezones and DST correctly with tempest/datetime?
- The library is timezone-aware, but correctness still depends on the system ICU and timezone database used at runtime. Pin those versions across containers, CI, and production, then add DST transition tests around your actual business boundaries. Carbon carries the same class of risk, but your team likely has more accumulated knowledge about its quirks.
- What alternatives should I consider for locale-aware date handling in Laravel?
- The pragmatic answer is CarbonImmutable combined with IntlDateFormatter from ext-intl, which covers most locale-correct formatting without a new dependency. Reach for tempest/datetime only where its semantics earn their keep, such as non-Gregorian calendar arithmetic or strongly typed interval distinctions in a booking or reporting domain. Encapsulate it behind domain-owned interfaces so a later switch back to Carbon stays cheap.