Laravel Dateinterval Cast Laravel Package

Product Decisions This Supports

• How duration data is modeled and stored. Many product concepts are really durations: trial lengths, grace periods, SLA response windows, retention windows, subscription cadence, lease/loan terms, rate-limit windows. This cast makes the "store an ISO 8601 duration string (e.g. P1D, PT30M) in a single column" option viable by hiding the parse/format boilerplate behind an Eloquent attribute cast.
• Build vs buy on glue code. This is not a platform decision; it is a ~one-file cast wrapping CarbonInterval. The real decision is "add a dependency" vs "write 20 lines in app/Casts," which should be judged on maintenance risk, not capability.
• API and consumer contract for durations. The cast controls the PHP-side type, not the serialized output. You still decide whether the API returns "P1D", 86400, or a humanized string — a cross-team contract that affects mobile, web, and partner integrations.
• Reporting and analytics constraints. If the roadmap includes aggregating durations in SQL (SUM, AVG, comparisons), an ISO string column is painful; that pushes you toward integer seconds in the database with a presentation-layer cast instead. This is a data-model decision a PM should be in the room for.
• Per-plan / per-tenant configurability. Normalizing durations to ISO 8601 lets product, billing, or a config service express tiered behavior without bespoke parsing per feature.

When to Consider This Package

Consider it when:

• You are on an existing Laravel 7/8 application with duration columns already stored as strings, and refactoring the schema is not worth the migration risk.
• You want CarbonInterval instances at the model boundary so feature code (comparisons, add() to dates, humanized display) stays readable.
• The team is small, the surface area is one or two models, and pinning a dependency is cheaper than owning code — with the assumption that you may need to fork it.

Look elsewhere when:

• Greenfield work. Write the custom cast yourself against CastsAttributes; it is small, testable, and removes the dependency entirely.
• Laravel 10/11 targets. The last release was September 2020 and the package advertises Laravel 7+; treat compatibility as unverified until you test it, not as a documented guarantee.
• You need active maintenance. 12 stars and a single 2020 release mean no support channel, no security response, and no deprecation path. Assume abandoned.
• The roadmap needs database-level aggregation or indexing on durations. Store integer seconds (or a computed column) and cast for presentation.
• You need calendar-aware semantics. "One month" from Jan 31 is not a fixed number of seconds; if business rules depend on that, the storage format and cast need explicit design, not a string column.
• You need validation, ranges, or multi-interval support. The cast is a serializer, not a validator.

How to Pitch It (Stakeholders)

To executives: A tiny open-source helper that eliminates hand-rolled parsing of duration values in our models, standardizing them on ISO 8601. Zero license cost, negligible code footprint. The trade-off is stewardship: it is a low-activity project last released in 2020, so we should treat it as code we adopt and own (vendored or reimplemented) rather than a dependency we rely on for support. Recommendation: use the pattern, own the code.

To engineering: It provides an Eloquent custom cast that round-trips a database string into a CarbonInterval/DateInterval. Before adopting we need to confirm PHP 8.x and current Laravel compatibility, add tests for nulls, zero, week and month units, and malformed input, and decide the column type and length. If any of that is contested, the cast is cheap enough to reimplement in-house with the behavior we actually want — which is likely the better long-term call given the project's activity level.