Datetime Field Type Laravel Package

Product Decisions This Supports

• Feature scoping for CMS-backed products. This is a field-type addon for the Anomaly Streams Platform (the engine behind PyroCMS). It answers a narrow but recurring product question — "how do editors set a date and time on an entry?" — without bespoke code. Relevant to editorial scheduling (publish-on / unpublish-at), event and calendar entries, promotions with start/end windows, deadlines, and cohort or booking timestamps.
• Build vs. buy (make that "build vs. adopt"). The honest answer is "adopt, don't build." It is MIT-licensed, free, and replaces a task most teams underestimate: a validated, formatted, admin-friendly datetime input plus its storage and presentation contract. Building this in-house yields no differentiation.
• Data-modeling consistency. Standardizing on one field type across content types means every datetime in the system is stored and rendered the same way. That is a reporting, querying, and export decision, not just a UI one — worth settling early, before content types multiply.
• Roadmap gate on the platform, not the package. Adoption only ever makes sense if the Streams Platform is already on your architecture diagram. This package should never be the reason you pick a CMS.
• Effort estimation. Treated as a low-risk, low-effort line item when the platform is a given; a hard blocker when it is not. That framing is what should reach a planning session.

When to Consider This Package

Adopt when all of the following hold:

• You are already running Anomaly Streams Platform / PyroCMS. The dependency is non-negotiable and effectively defines the package's usefulness.
• You need a datetime field inside Streams admin forms, and you would rather inherit the platform's field-type contract than maintain a parallel one.
• You are comfortable operating inside the addon ecosystem (composer-installed modules with their own versioning cadence) and can pin and patch versions.
• Zero license cost and full source availability matter to you — MIT grants fork and vendor rights, which is the escape hatch if upstream stalls.

Look elsewhere when:

• You are not on Streams. The package is inert outside its host platform. No partial reuse is possible.
• You need real temporal logic. Recurrence rules, date ranges, timezone conversion and display-in-user-locale, or business-calendar arithmetic are not what a field type does. Pair it with Carbon and explicit storage policy, or handle it in application code.
• You want a mainstream, actively supported Laravel path. A native datetime Eloquent cast plus a modern admin framework's picker (Filament's DateTimePicker, Laravel Nova's DateTime field, a Livewire component) is a better default unless the CMS is already fixed.
• Maintenance risk is unacceptable. Three stars and zero tracked dependents is a signal, not a verdict, but it points to a single-maintainer, low-bus-factor package. Verify the last commit date, open-issue responsiveness, and PHP/Laravel/Streams version compatibility before anything load-bearing depends on it. If it is critical, vendor or fork it — the license permits both.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed component that fills a routine gap in our CMS — letting editors set dates and times on content — so we are not paying engineers to reinvent a date picker. It carries no license cost and no vendor lock-in; the source is ours to fork if needed. Its strategic value is deliberately small and confined to CMS work: it does not expand what we can sell, it removes friction from what we already do. Approve it as a small line item, not as an initiative.

To engineering: Treat it as a thin adapter — a field type implementing the Streams Platform contract, wrapping a datetime input and its storage/formatting behavior. Low integration surface, low blast radius, but correspondingly low maintenance guarantees from upstream. Pin the version, confirm compatibility against our PHP and Streams versions, and write a test around the stored format so an upstream change cannot silently shift our data. If a date field becomes business-critical, plan to fork under MIT rather than wait for a fix.

Recommendation: Conditional adopt — only in Streams-based products, only for plain datetime capture, and only with the version pinned and a fork budgeted if the field becomes load-bearing. For greenfield Laravel work, choose the framework-native path instead.